页面性能优化

优化点	解决方案	效果
双向绑定数量过多 竞对设置单元格内部涉及双向绑定的输入组件过多，线上页面最多有88个该和抽屉中的编辑表格一样的组件，共计930+个（按每行最少6个来计算的）双向绑定的组件，严重拖累页面性能。 数据计算依据：88 = 竞对信息单元格数，930 = 155（编辑表格行数）*6（每行最低的双向绑定组件数） 问题截图：	将竞对设置的编辑表格改为纯文本展示表格，全局仅维护一个编辑表格，点击对应单元格的编辑按钮后，显示抽屉，将目标单元格数据带入编辑表格进行编辑操作，编辑完成后将修改后的数据同步到目标单元格对应的数据对象中。	通用的编辑表格组件数量由88个缩减到1个，双向绑定组件由930+个缩减到20个以内（线上数据每个编辑表格大概2-3行） 优化前 优化后 M3 Mac 进入页面后13s后可以进行页面交互 感官卡顿时间：6s 滚动会有明显卡顿 进入页面后6s后可以进行页面交互 感官卡顿时间：1s 滚动无卡顿 Windows测试机 页面崩溃无法打开 刷新后13s后可以进行页面交互 感官卡顿时间：5s 滚动无卡顿
2. 高并发重复请求​	这是在子组件请求接口，没有做接口缓存，导致调用N次请求。	缓存后，不切换城市只请求一次。
3. 树型选择器渲染函数时间复杂度高 线上场景组织节点数为5377个，当选择父级节点时，树型选择器renderTag方法使用了O(n2)的查找父节点遍历方法。 该renderTag方法在初始化、点击选择框、选择值、选择框失焦等多个事件中都会触发。 问题截图：	使用Map进行缓存，将函数时间复杂度降为O(n) // 优化前：filter+some 二层嵌套循环 时间复杂度为O(n2)const allTagList = data.filter((item) => {// 如果 item 有父节点，检查父节点是否选中if (item.parentId) {// 查找时间为O(n)return !data.some((dataItem) => dataItem.id === item.parentId);}// 如果 item 没有父节点，直接选中return true;}); // 优化后：Map直接读数时间复杂度为O(n) const allTagList = data.filter((item) => {// 如果 item 有父节点，检查父节点是否选中if (item.parentId) {// 使用 Map 的 has 方法，时间复杂度 O(1)return !selectedIdMap.has(item.parentId);}// 如果 item 没有父节点，直接选中return true;});	优化前 优化后 M3 Mac 点击全选果蔬组织 JS逻辑层执行时间4046ms 页面卡顿时间：6s 点击选择果蔬中心全选 JS逻辑层执行时间 6ms 页面卡顿时间：2s Windows测试机 点击全选果蔬组织，页面崩溃 点击选择果蔬中心全选 页面卡顿时间：4s 感官卡顿计时方式： 开始计时：使用计时器，点击全选果蔬按钮后开始计时 结束计时：页面可以随意滚动交互 感官卡顿时间 = 结束时间点-开始时间点 JS逻辑计时方式： 在renderTag问题函数的开始结束位置获取时间戳，在函数执行完毕后打印两者差值。 JS逻辑层执行时间 = 点击全选果蔬按钮后控制台输出的最长renderTag执行时间
4. 写法优化。 使用Set （n1）查找 避免模版直传方法渲染，替换为计算属性 ​