1.3 真實配置對比配置項默認全選跨頁全選數(shù)據(jù)范圍當前頁pageData全部查詢結果觸發(fā)事件源toggleAllSelection內部遍歷手動toggleRowSelectionselectedMap已選結果翻頁后丟失翻頁后保留提交邏輯從當前頁拿selection從業(yè)務層拿selectedMap組件狀態(tài)恢復不關心直接換data翻頁后按key回顯勾選這樣一列方案就清晰了跨頁全選不是“讓表格記住跨頁”而是把整張表格的選中結果從“臨時狀態(tài)”提升為“業(yè)務數(shù)據(jù)”永遠掛在業(yè)務層。這也是整篇的核心思路后面所有實現(xiàn)都是圍繞這一句話展開的。2. 兩條技術路線reserve-selection和手動Map管理怎么選講完原理肯定有人會問Element官方不是給了reserve-selection屬性嗎為什么還要自己存Map這個問題很自然因為官方方案確實是很多人第一眼看到的解。但我必須說清楚reserve-selection能用但它在生產(chǎn)環(huán)境有一堆隱藏前提很多團隊是踩完坑才回頭換手動管理的。我下面把兩條路線都擺出來你們自己權衡。2.1 reserve-selection官方保留選中的快速方案但有幾個隱藏前提先給快速方案的正解代碼。用reserve-selection實現(xiàn)跨頁保留選中代碼量非常少template el-table reftableRef :datapageData row-keyid selection-changehandleSelectionChange el-table-column typeselection reserve-selection width55 / el-table-column propname label姓名 min-width120 / el-table-column propdept label部門 min-width120 / /el-table /templateexport default { data() { return { pageData: [], selectedRows: [], }; }, methods: { handleSelectionChange(selection) { // reserve-selection 生效時selection 會包含其他頁已選中的行 // 但這里有一個關鍵點它保存的是行對象的引用不是快照 this.selectedRows selection; }, }, };用過的人都覺得爽翻頁切回來上一頁勾選的checkbox還在不需要寫一行恢復邏輯。但我后面在實際項目里逐步發(fā)現(xiàn)了它的坑而且每一個坑都挺隱蔽第一必須同時設置row-key且row-key對應的字段必須在數(shù)據(jù)刷新后保持不變。如果你的列表id是后端生成的篩選和排序后返回的新數(shù)據(jù)行id不變那沒問題但如果你用遍歷索引當row-key或者數(shù)據(jù)經(jīng)過前端處理后id變了reserve-selection會把舊key對應的選中殘留到一個根本不存在的行上表現(xiàn)就是“數(shù)據(jù)刷新后之前勾選的行沒在列表里但提交時還在selectedRows里”。這種鬼問題極難排查因為界面看起來是正常的。第二異步數(shù)據(jù)初始化的時序會坑人。表格先渲染空data再請求接口返回pageData這個過程中reserve-selection的regist邏輯有時會滯后。我遇到過一種場景搜索條件變更后重新查數(shù)據(jù)第一幀pageData是空數(shù)組選中狀態(tài)被清空一次等新數(shù)據(jù)回來時reserve-selection沒有恢復之前的key跨頁選中全丟了。這個bug不是必現(xiàn)但一旦出現(xiàn)在線上用戶罵的就是你。第三v-if重建表格、動態(tài)渲染el-table-column比如根據(jù)權限控制某些列顯隱、或者多次clearSelection()調用都會讓reserve-selection直接失效或誤清全量。很多后臺系統(tǒng)喜歡用v-if控制表格在“數(shù)據(jù)模式”和“空狀態(tài)模式”之間切換結果切換回來選中全沒了。你要是用reserve-selection就必須保證表格組件從創(chuàng)建到銷毀的生命周期內data和列配置都不能有大的結構變化。第四也是我最不推薦的一點selectedRows里存的是行對象引用不是快照。如果后續(xù)你對行數(shù)據(jù)做了修改比如編輯了某個字段或者接口返回時某些字段沒帶全提交時從selectedRows里取到的可能是舊引用或殘缺字段。如果你需要“勾選后立刻把這一行某字段鎖定允許后續(xù)修改但提交用鎖定值”這種需求reserve-selection就滿足不了。所以我的結論是reserve-selection適合“列表數(shù)據(jù)穩(wěn)定、不動態(tài)改列、不重建表格、只做勾選提交”的輕量場景。它寫起來快但你也必須承擔它的隱性約束。一旦你的系統(tǒng)里存在上面任何一條建議直接跳到手動管理方案。2.2 為什么生產(chǎn)環(huán)境我最終選擇了手動Map管理我在實際負責的中后臺項目里表格往往同時具備這些特征分頁 搜索篩選 后端排序 權限控制列顯隱 數(shù)據(jù)半路修改字段 切換賬號后重新加載數(shù)據(jù)。把這些特征疊在一起reserve-selection那套“組件替我記數(shù)據(jù)跟著行引用走”的機制就變得不可靠。這就是我后來放棄它改成手動維護一個selectedMap的根本原因。手動管理方案的核心就一句話選中狀態(tài)從“表格內部狀態(tài)”變成“業(yè)務組件的響應式數(shù)據(jù)”表格只負責展示當前頁哪些行被勾選真正的選中集合由你全權掌控。這樣做有幾個實實在在的好處數(shù)據(jù)和UI解耦selectedMap存的是行數(shù)據(jù)快照哪怕后續(xù)列表重新查詢、排序、甚至當前頁不存在這條數(shù)據(jù)只要key還在Map里提交時就能取到完整的行信息。各種邊界情況可編程切換篩選條件、清空選中、批量操作、限制最大選擇數(shù)全部可以在業(yè)務層寫邏輯不用猜組件內部行為。性能可預估選中集合的操作都是Map的set/delete/has時間復雜度O(1)幾千上萬條選中數(shù)據(jù)也不慌。當然代價也明顯代碼量變多了翻頁后要自己調toggleRowSelection回顯還要加標志位防止死循環(huán)。但對比線上數(shù)據(jù)錯亂的投訴我寧愿多寫這幾十行代碼。2.3 核心思路把選中狀態(tài)提升到業(yè)務層在寫代碼之前我要先把數(shù)據(jù)流畫出來這能幫你理解整個方案為什么設計成這樣正常勾選鏈路用戶點復選框 -select或select-all事件觸發(fā) - 根據(jù)勾選或取消向selectedMap寫入或刪除key - 表格繼續(xù)走它的正常渲染。翻頁恢復鏈路頁碼變化 - 請求新一頁數(shù)據(jù) -pageData更新 -watch或方法調用進入restoreSelection- 遍歷當前頁每行判斷key在不在selectedMap- 在則toggleRowSelection(row, true)回顯勾選。提交鏈路業(yè)務按鈕 - 遍歷selectedMap- 得到所有選中行做批量操作。三條鏈路彼此獨立selectedMap是唯一的數(shù)據(jù)源。這樣排序、篩選、分頁、跨頁全選都只是圍繞selectedMap做讀寫。還有一個小設計值得注意selectedMap的value我會存{...row}快照而不是直接存原行引用。原因有兩個一是防止后面對原行數(shù)據(jù)做修改時污染已選數(shù)據(jù)二是提交時拿到的字段齊整不會出現(xiàn)“勾選時明明有手機號提交時對象里沒有”的靈異事件。3. 手動管理跨頁選中的完整實現(xiàn)下面這套實現(xiàn)是我們在一個用戶量萬級的中后臺項目里跑過一年的方案按步驟復制就能用。我分三塊講模板和數(shù)據(jù)結構怎么搭、勾選和取消怎么處理、翻頁恢復有哪些細節(jié)必須注意。3.1 模板與數(shù)據(jù)結構搭建先看模板。注意我這里特意沒用reserve-selectionselection列的代碼和普通表格沒有任何區(qū)別template div classuser-table-wrapper el-table reftableRef v-loadingloading :datapageData row-keyid :row-class-namerowClassName selecthandleSelect select-allhandleSelectAll el-table-column typeselection width55 / el-table-column propname label姓名 min-width120 / el-table-column propphone label手機號 min-width140 / el-table-column propdept label部門 min-width120 / el-table-column propcreateTime label創(chuàng)建時間 min-width170 / /el-table el-pagination classtable-pagination background layouttotal, prev, pager, next, sizes :current-pagepage :page-sizepageSize :totaltotal current-changehandlePageChange size-changehandleSizeChange / /div /template再定義數(shù)據(jù)結構。這里我推薦用Map而不是普通對象因為Map對key的類型沒有限制插入順序也好控制遍歷性能也比對象好export default { data() { return { page: 1, pageSize: 50, total: 0, loading: false, pageData: [], // 跨頁選中的核心數(shù)據(jù)結構 // key: row-key 對應的字段值例如 id // value: 行數(shù)據(jù)快照 { ...row } selectedMap: new Map(), // 防止恢復勾選時觸發(fā) select/select-all 事件導致死循環(huán) isRestoring: false, }; }, };這里有兩個容易忽略的設計。一個是isRestoring標志位。沒有它restoreSelection里調toggleRowSelection會觸發(fā)select事件handleSelect又把數(shù)據(jù)寫進selectedMap而selectedMap變動如果又引起別的地方重新渲染就會出現(xiàn)事件風暴輕則選中狀態(tài)錯亂重則直接棧溢出。我在剛實現(xiàn)這套邏輯時就沒有標志位頁面一翻頁就卡死后來排查半天才找到是這里互相觸發(fā)。另一個是Map的value為什么要用{ ...row }而不是直接存row。前面提過這是為了防污染。舉個例子用戶在第1頁勾選了一行然后表格發(fā)請求刷新了列表第1頁的這行數(shù)據(jù)可能被新對象替代。如果你存的是舊引用提交時拿到的內容還是舊的反而沒問題但如果你在勾選后某個彈窗里修改了原行數(shù)據(jù)比如改狀態(tài)字段舊引用對應的對象會和列表里顯示的不一致。存快照就能保證selectedMap里永遠是你勾選那一刻的狀態(tài)可控性最強。3.2 勾選、取消勾選、全選的處理邏輯勾選和取消走的是select事件。這個事件回調里有兩個參數(shù)selection變化后所有選中行的數(shù)組和row當前操作的那一行。要判斷是勾選還是取消最簡單的方法就是看row還在不在selection里handleSelect(selection, row) { // 恢復勾選期間觸發(fā)的事件直接忽略 if (this.isRestoring) return; const key row[this.rowKey]; const isSelected selection.includes(row); if (isSelected) { // 勾選寫入快照 this.selectedMap.set(key, { ...row }); } else { // 取消刪除key this.selectedMap.delete(key); } }這里有個細節(jié)值得說明selection.includes(row)依賴的是“操作的行對象引用”。Element UI在渲染時用的是pageData里的行對象你操作時傳入的row也是同一個對象引用所以includes能正確判斷。如果因為某些原因你發(fā)現(xiàn)includes不準比如對行對象做過淺拷貝可以改成用key判斷const isSelected selection.some(item item[this.rowKey] key);兩條路都對選一個順手的即可。全選和取消全選走的是select-all事件。它只有一個參數(shù)selection也就是操作后當前頁選中行的集合。全選時selection包含當前頁所有行取消全選時selection為空數(shù)組。但這里有個大坑我必須單獨強調一下Element UI的表頭全選checkbox點擊一次在部分選中狀態(tài)下會執(zhí)行“先清空再全選”兩個動作也就是說selection參數(shù)會經(jīng)歷“空數(shù)組 - 全部行”的過程。你在二次點擊時如果拿selection直接覆蓋selectedMap會把之前所有頁的選中都清掉。所以處理select-all一定要用“增量合并”而不是“整體覆蓋”handleSelectAll(selection) { if (this.isRestoring) return; // 判斷當前是“全選”還是“取消全選” // 全選時當前頁的每一行都應該在 selection 里 const isAllSelected this.pageData.every(row selection.includes(row)); this.pageData.forEach((row) { const key row[this.rowKey]; if (isAllSelected) { // 全選把當前頁所有行寫入Map this.selectedMap.set(key, { ...row }); } else { // 取消全選把當前頁所有行從Map中刪除 this.selectedMap.delete(key); } }); }這段代碼的關鍵在于isAllSelected的判斷。它不關心selection經(jīng)歷過幾次變化只看當前這一幀的selection是否覆蓋了pageData全部行。這樣寫無論用戶在什么選中狀態(tài)下點全選結果都是穩(wěn)定的要么把這頁所有行合并進全局要么把這頁所有行從全局移除其他頁的選中不受影響。3.3 翻頁后恢復勾選的細節(jié)不能用舊引用翻頁或改變每頁條數(shù)后pageData會被新的數(shù)據(jù)覆蓋。此時表格本身是不帶任何選中狀態(tài)的需要我們在數(shù)據(jù)到位后手動恢復。恢復邏輯放在loadPage的末尾async loadPage() { this.loading true; const { list, total } await fetchUserList({ page: this.page, pageSize: this.pageSize, }); this.loading false; this.pageData list; this.total total; // 數(shù)據(jù)到位后恢復勾選 this.restoreSelection(); }, restoreSelection() { if (!this.$refs.tableRef) return; this.isRestoring true; this.$nextTick(() { this.pageData.forEach((row) { const key row[this.rowKey]; if (this.selectedMap.has(key)) { this.$refs.tableRef.toggleRowSelection(row, true); } }); this.isRestoring false; }); }這個restoreSelection是整個方案里最容易寫錯的地方我?guī)缀趺看卧u審都能看到同事在這里踩坑。最常見的一個錯誤是把selectedMap里存的舊行對象直接傳給toggleRowSelection而不是用當前pageData里的行對象。比如// 錯誤示例 this.selectedMap.forEach((row) { this.$refs.tableRef.toggleRowSelection(row, true); });這樣寫翻頁后表格根本不會有任何勾選。原因在于toggleRowSelection內部會拿傳入的行和當前data中的行做匹配由于你傳的是舊頁面的行對象引用新pageData里每一行都是新創(chuàng)建的對象引用對不上組件認為“這一行不在表格里”自然不會勾選。正確做法永遠是遍歷當前pageData從selectedMap里查key然后再回設。另外restoreSelection里this.$nextTick也是必須的。因為this.pageData list之后Vue需要等到DOM更新完表格內部的data屬性才會同步成新數(shù)據(jù)。如果不等nextTick直接遍歷pageData調toggleRowSelection此時表格內部可能還在處理舊數(shù)據(jù)會出現(xiàn)恢復失敗或狀態(tài)殘留。還有一個性能問題容易被人忽略當一頁有50條數(shù)據(jù)循環(huán)調toggleRowSelection50次每次都會觸發(fā)一次表格內部的選中狀態(tài)更新。如果回顯邏輯還觸發(fā)了select事件即使有isRestoring攔截也會白白多走一輪方法調用。所以建議在restoreSelection開頭就置isRestoring truenextTick的回調里循環(huán)完再置回false把整個恢復過程隔離成一次“靜默操作”。3.4 清空全部與提交數(shù)據(jù)跨頁全選的方案里這兩個方法可以說是“配套服務”缺一個都難受。清空全部指的是把selectedMap清空的同時把當前頁表格上可見的勾選也全部取消clearSelection() { // 清空業(yè)務層的選中集合 this.selectedMap.clear(); // 清空當前頁表格可見的勾選 this.$nextTick(() { this.$refs.tableRef.clearSelection(); }); }這里要注意順序先清selectedMap再調clearSelection()。因為clearSelection()會觸發(fā)select/select-all事件如果此時selectedMap還沒清空事件回調里會往Map里寫入當前頁所有行的key導致“清空失敗”。反過來先清Map再清表格事件觸發(fā)了也無所謂handleSelect和handleSelectAll判斷到selectedMap已經(jīng)沒有對應key自然不會寫入。提交數(shù)據(jù)時把selectedMap的values取出來就行function handleSubmit() { if (this.selectedMap.size 0) { // 給個提示別讓用戶直接提交空數(shù)據(jù) this.$message.warning(請先勾選要處理的用戶); return; } const selectedRows Array.from(this.selectedMap.values()); // 調用批量接口 await batchOperation(selectedRows); }如果你要按勾選順序提交Map本身會維護插入順序Array.from(this.selectedMap.values())拿到的數(shù)組基本就是用戶勾選的先后順序。但如果你中途刪掉某個key再重新添加Map會把它放到最后這一點如果業(yè)務要求嚴格按操作順序需要額外維護一個orderList數(shù)組來記錄這里就不展開寫了。4. 一不留神就翻車的邊界情況跨頁全選實現(xiàn)出來只是第一步。真正決定方案好不好用的是它在各種異常場景下能不能穩(wěn)住。下面這幾個邊界情況都是我在真實項目里被問過、被投訴過、現(xiàn)場排查過的每個都值得拿出來單獨說。4.1 排序篩選后的選中語義問題先給結論跨頁全選和排序、篩選不是天然兼容的你必須先和產(chǎn)品經(jīng)理確認“已選”到底代表什么語義。我遇到的真實需求是這樣的用戶在第1頁勾了3個人然后在搜索框里輸入“離職”點擊查詢列表變成了離職員工之前勾選的3個人不在結果里。此時界面上“已選3人”是否還應該顯示如果顯示用戶可能看不到自己選了誰很容易誤解成“這3人是當前條件篩選出來的結果”如果不顯示但提交時又把3個人帶上用戶會在最后一步覺得莫名其妙。后來我們定的方案是所有篩選、排序操作都不會自動清空selectedMap但會在表格上方浮動一條提示已選 N 人當前查詢條件下顯示 M 人操作將作用于全部已選。同時提供“清除已選”按鈕。這條提示的M怎么算就是當前pageData里有多少行的key命中selectedMapconst currentPageSelectedCount computed(() this.pageData.filter(row this.selectedMap.has(row[this.rowKey])).length );這樣用戶對“哪些選中可見、哪些不可見”一目了然投訴率直線下降。另外如果你的業(yè)務在篩選后確實希望“只作用于當前條件下的選中”那就改成篩選時自動調用clearSelection()并在篩選組件上給一個明顯的“已有選中數(shù)據(jù)切換篩選將清除”的提示。4.2 排序重排與數(shù)據(jù)刷新的競態(tài)問題中后臺列表幾乎都有排序。點表頭排序后后端重新返回列表此時pageData的數(shù)組順序變了但行的id沒變。只要我們的回顯邏輯基于key而不是基于順序排序后選中狀態(tài)就能正確恢復。這里有個問題反而比排序本身更隱蔽連續(xù)操作導致的接口競態(tài)。舉個具體場景用戶在第1頁卡頓的情況下連續(xù)點了第2頁、第3頁前端會發(fā)出兩次分頁請求后一次響應覆蓋前一次。如果兩次請求之間網(wǎng)絡速度差異大可能出現(xiàn)第2頁的響應比第3頁晚到最后表格停在“page3”的翻頁指示器上但展示的卻是第2頁的數(shù)據(jù)。這時候restoreSelection恢復的是第2頁的選中頁面狀態(tài)混亂。解決競態(tài)的標準做法是給請求編號只有最新編號的響應允許覆蓋數(shù)據(jù)data() { return { querySeq: 0, }; }, async loadPage() { const currentSeq this.querySeq; this.loading true; const { list, total } await fetchUserList({ page: this.page, pageSize: this.pageSize, }); this.loading false; // 過期響應直接丟棄 if (currentSeq ! this.querySeq) return; this.pageData list; this.total total; this.restoreSelection(); }這個querySeq字段我在所有分頁接口里都會加成本幾乎為零但能防住絕大部分連續(xù)翻頁、連續(xù)篩選造成的狀態(tài)錯亂。有時候用戶反饋“表格偶爾顯示和翻頁按鈕對不上”十有八九就是缺這個。4.3 表格銷毀與賬號切換時殘留臟數(shù)據(jù)后臺系統(tǒng)經(jīng)常有切換部門、退出登錄、彈窗關閉等場景表格組件被銷毀或v-if置為false。如果selectedMap是頁面級data組件銷毀時Vue會一起回收問題不大。但如果表格在彈窗里彈窗關閉后selectedMap還在父組件內存里重新打開彈窗時上一次的選中數(shù)據(jù)會殘留在Map里。表現(xiàn)就是用戶這次打開彈窗什么都沒勾提交的時候卻提示“已選50人”。這個問題我建議在進入表格頁面前統(tǒng)一初始化selectedMap并在關閉時清理openDialog() { this.selectedMap.clear(); this.dialogVisible true; }, closeDialog() { this.dialogVisible false; this.selectedMap.clear(); if (this.$refs.tableRef) { this.$refs.tableRef.clearSelection(); } }這里的核心原則是selectedMap的生命周期必須和業(yè)務會話一致不能比表格組件更長。如果你把Map定義在全局store里記得在退出相關業(yè)務模塊時手動清空不然這次選中的數(shù)據(jù)會跟著用戶跑到下一個業(yè)務里去。4.4 alert、messagebox、批量操作之后的選中保持問題還有一種情況用戶勾選了幾十行執(zhí)行批量操作后接口報錯了。此時要不要清除選中不同業(yè)務的答案完全不同。我的經(jīng)驗是操作失敗時必須保留選中操作成功時可以保留也可以清除但必須給用戶明確的反饋。很多系統(tǒng)采用“執(zhí)行后自動清空”結果接口超時用戶還得重新一頁一頁翻回去再勾選體驗極差。我會把“提交”和“清空”拆成兩個動作只在批量操作成功且用戶確認不再處理其余數(shù)據(jù)時才清空。另外像MessageBox.confirm這類全局彈窗如果用戶點擊“確定”后我們把selectedMap清空了后續(xù)彈出的成功提示就別再依賴這個Map顯示數(shù)量否則會出現(xiàn)“已選0人但提示成功操作3人”的笑話。5. 跨頁全選配套的體驗優(yōu)化與性能保障模塊跑通之后就要考慮把它做得更好用、扛得住數(shù)據(jù)量了。這一部分我會結合表格滾動條、滾動條寬度、4000條假數(shù)據(jù)、組合篩選、獲取列寬這幾個中后臺里經(jīng)常連在一起出現(xiàn)的問題逐個講我在項目里的處理方案。5.1 已選N條提示條與表格的聯(lián)動布局跨頁全選之后產(chǎn)品大概率會要求“在表格上方顯示已選N條”。這個提示條最怕兩件事一是翻頁后數(shù)字不更新二是和表格列對不齊。數(shù)字更新好辦用Map的size或者一個響應式的selectedCount就能實時顯示。關鍵是布局對齊。有些設計會把提示條放在表格上方里面還有“清除”按鈕。如果表格開啟了固定列提示條的左邊緣會和表格左邊緣對齊看起來是整齊的。但如果提示條里還有“查看已選”之類的下拉面板它的寬度又不能超過表格本身。我的做法是給表格外層套一個.table-container提示條放在容器內、表格之上寬度設成100%再配合box-sizing: border-box和表格本身的border設置基本能保證視覺對齊。如果提示條需要對齊到某個具體列比如對齊操作列就得獲取列寬了這個我會在第5.4節(jié)專門講做法。5.2 大數(shù)據(jù)量下表格滾動條和固定列的性能細節(jié)再來說熱詞里那個“el-table顯示4千條假數(shù)據(jù)”。我先給一個個人建議不要真的在一個頁面上讓el-table渲染4000行。很多人做原型時喜歡Array.from({ length: 4000 }, ...)生成假數(shù)據(jù)鋪滿表格看著很震撼但el-table并不是虛擬滾動表4000行全部渲染會導致DOM節(jié)點爆炸滾動條拖起來掉幀勾選checkbox更是卡到?jīng)]法用。如果只是做演示想要“一屏滾到底”的效果比較簡單的方法是給表格設置固定的height或max-height讓el-table自己產(chǎn)生內部滾動條el-table :datapageData height600 row-keyid !-- columns -- /el-table這樣做表格內部滾動DOM渲染仍然只處理可見區(qū)域之外的滾動容器結構雖然4000行全量渲染依舊存在但至少不會撐滿整頁。屏幕高度有限用戶滾動的體驗會好不少。但如果你要的是真正的4000行流暢滾動我只能說el-table做不到得換支持虛擬滾動的方案比如第三方table組件?？珥撊x這套手動Map管理的邏輯和那些表格組件同樣適用你只需要把“表格組件的事件回調”替換成對應組件提供的select/select-all事件即可selectedMap的核心設計不用變。滾動條寬度的問題也要留個心。el-table開啟固定列后右側會出現(xiàn)一個滾動條當滾動條和固定列重疊時表頭和表體的列寬容易對不上尤其是在窗口尺寸變化、表格寬度被百分比控制時。我在項目里遇到過一次表格右側固定了“操作”列但橫向滾動條被操作列遮住了一半用戶很難拖動。除了調整固定列寬度、給滾動條留位置之外還可以在表格數(shù)據(jù)變化后主動調用一次this.$nextTick(() { this.$refs.tableRef.doLayout(); });doLayout()是el-table的實例方法會重新計算列寬和布局。列寬對不齊、滾動條錯位、固定列錯位這些問題在數(shù)據(jù)異步加載后經(jīng)常出現(xiàn)調一下基本都能解決。注意一定要放在nextTick里否則DOM還沒更新完重新計算的是舊布局。5.3 組合篩選組件和跨頁全選的聯(lián)動策略大多數(shù)中后臺表格上方都掛著組合篩選組件關鍵字輸入框、部門下拉、狀態(tài)多選、日期范圍。篩選一多跨頁全選的交互就復雜了。我踩過的坑是這樣的用戶在“全部狀態(tài)”下勾了100人然后選擇“在職”狀態(tài)篩選此時列表只顯示在職用戶之前的100人里有80人還在Map里但列表里看不全。用戶并不知道這100人里有20人是離職的于是點擊“全選”想繼續(xù)把在職的都選上結果100 全部在職數(shù)量遠大于預期。處理這種聯(lián)動我總結出一個比較穩(wěn)的交互模型篩選條件變化時不自動清空selectedMap但提示條上明確展示“已選N人含當前篩選條件之外的M人”。如果用戶希望只選當前結果集可以先點“清除已選”再重新勾選。如果點擊表頭全選只把當前結果集合并進selectedMap不影響其他條件里的已選數(shù)據(jù)。提交時提示“將處理全部已選N人”并列出前幾條和后綴“等N人”。這個方案雖然不能讓所有產(chǎn)品經(jīng)理滿意但它在“數(shù)據(jù)安全”和“操作效率”之間做到了均衡至少不會出現(xiàn)用戶不知道自己在操作什么的情況。組合篩選組件還會帶來一個技術點篩選條件在組件內部但表格數(shù)據(jù)請求需要一個統(tǒng)一的參數(shù)對象。建議把篩選表單的model放在一個獨立的computed或ref里在loadPage里把它展開到請求參數(shù)中避免每個篩選控件單獨修改請求參數(shù)保證跨頁全選時重新請求的數(shù)據(jù)和篩選條件總是對應的。5.4 獲取列寬做自定義表頭的對齊計算最后說一個相對進階但很實用的點獲取el-table的列寬。為什么要獲取列寬因為當你想在表頭上方加自定義內容比如“批量操作欄”的下拉、篩選面板的位置定位、表頭某個checkbox的樣式定制時只能用絕對定位或對齊計算這時候列寬就是唯一的坐標系依據(jù)。官方并沒有直接暴露一個“獲取某一列寬度”的實例方法但我們可以從兩條路拿到。第一條是通過組件的storeconst columns this.$refs.tableRef.store.states.columns; columns.forEach((col) { console.log(col.label, col.width, col.realWidth); });col.width是用戶顯式設置的寬度col.realWidth是經(jīng)過計算后的真實寬度。固定列和自適應列在realWidth上更可靠。第二條是直接從DOM里量const ths this.$refs.tableRef.$el.querySelectorAll(.el-table__header thead th); ths.forEach((th) { console.log(th.getBoundingClientRect().width); });DOM測量方式最直觀但依賴樣式渲染完成通常也要包在nextTick里用。我一般優(yōu)先用store.states.columns拿邏輯寬度用getBoundingClientRect做最終校正。拿到的列寬可以用來給“表頭全選”替代方案做精確的checkbox定位或者做一個跟隨表頭橫向滾動的“已選N人”操作條。順帶說一個列寬相關的高頻bug動態(tài)切換列的顯示隱藏時表格列寬會錯亂。這是因為v-if變更后表格內部的列緩存沒有自動清理。解決方式是給表格加key讓列配置大幅變化時重建組件或者手動doLayout()重新排布。如果列切換頻繁、性能要求高優(yōu)先doLayout如果列配置切換不頻繁直接重建組件最穩(wěn)反正有selectedMap兜底組件重建了選中數(shù)據(jù)也不會丟。結尾跨頁全選這個功能代碼量不大但牽扯到的邊界場景一點也不少。我做下來最大的體會是不要和表格組件較勁要讓組件只負責它擅長的事——展示和交互真正需要長期保存的數(shù)據(jù)一定要握在自己手里。這也是為什么整篇文章花了大力氣講selectedMap的設計而不是教你怎么改Element源碼或者鉆reserve-selection的空子。最后再分享一個我在實際項目中驗證過的小技巧如果你是用Vue3 Element Plus這套方案的代碼風格基本不用變唯一要注意的是toggleRowSelection的第三個參數(shù)在不同版本里有差異恢復勾選時記得nextTick和isRestoring這兩個保險一起上能幫你省掉大半查bug的時間。還有一個很容易被忽略的點就是測試?？珥撊x涉及分頁、篩選、排序、批量操作、失敗重試等場景手工點幾遍很難覆蓋全。我建議用無頭瀏覽器或者自動化測試把“跨頁勾選 - 翻頁 - 回顯 - 提交”這樣一條主鏈路固定下來每次發(fā)版前跑一遍。別問我為什么這么建議我吃過一次線上漏測的虧那次就是篩選后全選計數(shù)不對用戶反饋刷了一屏。