m0_48940868的博客

项目场景（需求）：1.分步骤填写数据，填写并上传业务Excel表，完成校验，并生成结果2.生成的结果要和 业务Excel表一致，便于用户比较3.若未填写正确，则提示用户错误信息，且重新提交项目新建流程：如下图所示：业务Excel表：如图所示：功能实现思路：1. 页面整体结构： 就是在index.vue里面 渲染4个不同的子路由2. （重点）实现点击上传Excel——后端完成校验——生成预览效果 思路：请求接口，上传文件后端通过Python解析文件，把业务表格拆分成多个

项目场景：后端：数据拿去，自己玩个日志管理页面出来{ "curent": { "ub_real_name": "扬钧测试账号", "op_time": "2022-03-18 14:15:08", "op_type": "修改", "op_detail": { "商机编码": "2022031717320012345", "运维厂商": "运维方", "厂商类型

项目背景：还是前几篇文章中所涉及到项目，现在 才 做权限控制不过还好，现在这个项目的业务还不复杂，还来得及，只能这样安慰自己如下图所示：在login 成功以后， 后端返回 一些用户账号的基本信息 、功能权限 和 身份权限这样本身并没有什么问题，前端取到数据后，把数据存起来然后全局展示和限制就行了现在问题来了，客户提了一个让我和后段都傻眼的需求客户： 我不想从你们登录页面进，我想从我们其他系统跳进你这个系统，方便我们操作人员直接进来填数据，新增项目等等老板： 行，没毛病！后端：老板，

项目场景：如图所示解释：这是常见的多条件查询业务，一般都是传对应的参数，查对应的列表数据问题描述后端现在规定：下拉或者输入框里面有值，才把对应对应的字段和值传过来，反之，不要传字段过来！如图：先看下原来传参数的代码部分：1.一开始放到计算属性里面，考虑到共用的时候好处理，也减少了代码， 要传参的时候直接 this.params_search 即可2.但是 缺点也是很明显的，这种数据结构已经成型，要完成最开始说的那种要求， 会在 params_search里面写很多的if判断，非

项目场景：常见的表单填写中都会遇到，比如新增信息，修改信息等，如下图相信大家对上面的验证都非常熟悉了，不多哔哔本篇文章主要 想写 验证规则自定义 相关的内容验证是否是合法手机号（举例）实现下图所示：实现步骤：step 1准备好 reg表达式 ， 百度即可 电话号码—— /^(((13[0-9]{1})|(15[0-9]{1})|(18[0-9]{1}))+\d{8})$/step 2model 和 ref 最好一致 prop验证的phone_number

项目场景(如图)：这是常见的一种权限设置即：参数只有city，那么只有对应city的权限，----------- 成都就只能查成都的数据再加一个county="武侯区"的话，那么就只能查“武侯区”及其下属的数据，不能再查成都的数据了。问题描述：要完成这个功能，要明确两点：(1) JS 获取地址栏参数，操作完后 最好return 成一个 object，这样方便判断(2) 由于在此种业务场景下，页面一加载，就应该结合 地址栏参数来做 if 判断，达到下图的效果，那么，在请求回来一整

业务场景：（如下图所示）【从上图可以知道，这是很常见的多tab切换场景，切换时，下面的 table数据会发生变化，而且页面的上的操作按钮也需要在当前table页完成操作】具体业务：（如下图所示）优化前：（究极不科学，不推荐）由于每个table的表头字段基本都不同，最初为了图省事，就v-if了6个table，来分别展示不同的table，后端就没怎么改动，只需要前端自己判断下就行了。这样做的后果就是：代码沉积，垃圾代码太多了，看也看得心烦，更恐怖的是，如果是6个table，那么就应该有6个编辑的

常见业务代码记录：1.处理el-tab 折叠echarts 图表 bugdata() { return { active_name:"1", active: 1, tab_refresh:{ lock1: true, lock2: false, }, }; }, methods: { handleqie(val) { this.active = val; },

项目场景：还是上篇文章提到的项目，前不久本地测试无异常，现在已经在线上运行了，但是好日子（摸鱼）没过多久，后端就找上门了…后端：现在线上由于并发请求太多了，要是有那么一两个请求响应慢了一点的话，非常容易超时然后挂掉。理想的我：请求响应慢也找我，真当我前端好欺负？真实的我：行吧大哥，那我这边控制一下同时请求的次数，做一个分批次请求，你看这样行不？后端：这还差不多，别一次性给我那么多请求，我处理不过来，我不想改代码理想的我：我X你XX的，你不想改就丢给我，才13个请求就整不动了？想想双11人家的后

关于本次项目的总结一、得与失1.存在的 问题：JS基础知识严重不足:时间格式化处理完全不熟悉，后端需要的格式无法正常处理并且传参项目开发时，对于业务功能，业务逻辑的预判失误，导致开发延期，对于业务逻辑的不熟悉关于一些JS常规数据处理不熟悉，数组，对象一些常用的排序、遍历、分类、字符串截取对于接口数据的处理上，不能优雅地展示出对应数据，而是只关心 后端给我啥就展示啥，不思考数据结构本身的关联性，从而导致[5]在postman模拟请求时，应该用不同的参数尽可能地多次测试，拿回来的数据做好备份，并