1. 雙向綁定數量過多

競對設置單元格內部涉及雙向綁定的輸入組件過多，線上頁面最多有88個該和抽屜中的編輯表格一樣的組件，共計930+個（按每行最少6個來計算的）雙向綁定的組件，嚴重拖累頁面性能。

數據計算依據：88 = 競對信息單元格數，930 = 155（編輯表格行數）*6（每行最低的雙向綁定組件數）

問題截圖：

將競對設置的編輯表格改為純文本展示表格，全局僅維護一個編輯表格，點擊對應單元格的編輯按鈕后，顯示抽屜，將目標單元格數據帶入編輯表格進行編輯操作，編輯完成后將修改后的數據同步到目標單元格對應的數據對象中。

通用的編輯表格組件數量由88個縮減到1個，雙向綁定組件由930+個縮減到20個以內（線上數據每個編輯表格大概2-3行）

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;});

感官卡頓計時方式：

1. 開始計時：使用計時器，點擊全選果蔬按鈕后開始計時

2. 結束計時：頁面可以隨意滾動交互

感官卡頓時間 = 結束時間點-開始時間點

JS邏輯計時方式：

在renderTag問題函數的開始結束位置獲取時間戳，在函數執行完畢后打印兩者差值。

JS邏輯層執行時間 = 點擊全選果蔬按鈕后控制臺輸出的最長renderTag執行時間

4. 寫法優化。

使用Set （n1）查找

避免模版直傳方法渲染，替換為計算屬性

?