1. 分頁到底在解決什么問題先想清楚場景再動手先講個現(xiàn)象。我見過不少剛接觸 View UI以前叫 iView的開發(fā)者拿到 Table 和 Page 組件后第一件事就是照著文檔抄一遍代碼抄完發(fā)現(xiàn)表格能顯示數(shù)據(jù)、頁碼也能點以為萬事大吉。結果一上生產(chǎn)環(huán)境就出問題數(shù)據(jù)量到了幾千條頁面直接卡頓、翻頁時請求重復發(fā)送、搜索之后頁碼還停留在舊位置、刪掉當前頁最后一條數(shù)據(jù)后表格變成空白頁……每一個都是線上事故級別的體驗問題。其實分頁這件事本質上不是把數(shù)據(jù)切開一頁頁展示那么簡單它背后有兩層邏輯一是減少單次渲染的數(shù)據(jù)量二是把展示狀態(tài)和業(yè)務狀態(tài)解耦。你不把這兩層想清楚寫出來的分頁代碼永遠是在打補丁。用 View UI 的 Table 和 Page 組合做分頁是 Vue 生態(tài)里很經(jīng)典的一套方案。Table 負責展示數(shù)據(jù)Page 負責提供交互入口兩者通過 data 和事件串聯(lián)起來。這套組合在我的項目里用了很多年今天把完整思路、踩過的坑、以及封裝成通用組件的方案一次性寫完希望能幫你省掉一些不必要的折騰。先說基礎概念方便后面統(tǒng)一語言current / currentPage當前頁碼從 1 開始。pageSize / page-size每頁顯示條數(shù)。total數(shù)據(jù)總條數(shù)。dataTable 當前頁實際要渲染的數(shù)據(jù)數(shù)組。on-changePage 組件頁碼變化時觸發(fā)的回調函數(shù)。2. 前端分頁還是服務端分頁這個選擇題決定代碼結構很多人在第一步就選錯了方向。我接到過的分頁相關咨詢里至少有一半人分不清前端分頁和服務端分頁該在什么場景下用。這里直接給結論數(shù)據(jù)量小幾百到一千條以內(nèi)且一次性從接口拿全量數(shù)據(jù)用前端分頁。數(shù)據(jù)量大幾千條以上或者接口本身就支持分頁參數(shù)用服務端分頁。什么情況下前端分頁會出問題舉個例子一次接口返回 5000 條數(shù)據(jù)你把它們?nèi)M Table雖然 Table 會一次性渲染出所有行但 Page 組件的頁碼計算、瀏覽器 DOM 節(jié)點數(shù)量、重排重繪帶來的性能消耗都會讓你在低端設備上體驗到明顯的卡頓。更嚴重的是如果表格列的字段很多5000 行乘以 10 列那就是 5 萬個單元格瀏覽器直接崩給你看。服務端分頁則是把當前頁顯示哪些數(shù)據(jù)這個責任交給后端前端只告訴后端我要第幾頁、每頁多少條后端返回當前頁的數(shù)據(jù)和總數(shù)。這種方式的優(yōu)點是前端性能壓力小缺點是每次翻頁都要等網(wǎng)絡請求交互上必須處理好 loading 狀態(tài)和錯誤重試。我個人的判斷標準很簡單如果接口返回的數(shù)據(jù)總量超過 1000 條或者接口本身已經(jīng)給了 page 和 size 參數(shù)就毫不猶豫走服務端分頁。分頁的本質是數(shù)據(jù)訪問的邊界控制這個邊界越靠前系統(tǒng)的可擴展性越好。下面這張表是我選型時的常用參考標準供你直接抄作業(yè)對比維度前端分頁服務端分頁數(shù)據(jù)量建議1000 條以內(nèi)任意數(shù)量尤其適合大數(shù)據(jù)量接口請求次數(shù)1 次頁面加載時每次翻頁 1 次交互響應速度快無網(wǎng)絡等待慢依賴網(wǎng)絡延遲加載狀態(tài)處理基本不需要必須處理后端改動無需要支持分頁參數(shù)維護成本低中推薦場景數(shù)據(jù)字典、配置列表、報表預覽用戶列表、訂單列表、操作日志3. Table 和 Page 的基礎組合從一份能跑通的代碼說起確定了分頁方式后我們直接寫代碼。這里先用一份前端分頁的完整示例來拆解核心邏輯因為它的代碼鏈路最短最適合理解 Table 和 Page 的協(xié)作關系。假設我們從接口拿回一份 200 條數(shù)據(jù)的用戶列表每頁顯示 10 條需要在表格底部用 Page 組件控制翻頁。先看完整代碼template div classuser-list Table :columnscolumns :datapageData stripe/Table Page :totalmockData.length :currentcurrentPage :page-sizepageSize show-total on-changehandlePageChange stylemargin-top: 16px; text-align: right / /div /template script export default { name: UserList, data() { return { columns: [ { title: ID, key: id, width: 80 }, { title: 姓名, key: name, minWidth: 120 }, { title: 郵箱, key: email, minWidth: 200 }, { title: 創(chuàng)建時間, key: created_at, minWidth: 180 } ], // 模擬全量數(shù)據(jù)實際場景中來自接口 mockData: [], currentPage: 1, pageSize: 10 } }, computed: { pageData() { const start (this.currentPage - 1) * this.pageSize const end start this.pageSize return this.mockData.slice(start, end) } }, created() { this.loadMockData() }, methods: { async loadMockData() { // 模擬接口請求 const res await fetch(/api/user/list) this.mockData await res.json() }, handlePageChange(page) { this.currentPage page } } } /script這套代碼的核心邏輯只有三步全量數(shù)據(jù)存在 mockData 里作為分頁的數(shù)據(jù)源。computed 里的 pageData 負責切頁根據(jù)當前頁碼和每頁條數(shù)動態(tài)算出當前頁該顯示哪些數(shù)據(jù)。Page 組件的 on-change 事件負責更新 currentPagepageData 隨之重新計算表格自動刷新。這里有個關鍵設計Table 綁定的是pageData而不是mockData。這個slice的動作就是前端分頁的核心它保證了 Table 每次只拿到 10 條數(shù)據(jù)而不是把 200 條全部渲染出來。這樣做的直接好處是 DOM 節(jié)點數(shù)量大幅減少頁面重排開銷明顯下降。但如果你只看到了這一步那還沒入門。我前兩年接手過一個項目同事把這段邏輯寫成了handlePageChange(page) { this.mockData this.mockData.slice(page * 10) // 錯誤寫法 }他以為翻頁就是把數(shù)據(jù)切掉一段結果翻到第 3 頁后每翻一次數(shù)據(jù)就少掉一部分再往回翻全亂了。正確做法永遠是保留全量數(shù)據(jù)源用計算屬性去切當前頁而不是去修改數(shù)據(jù)源本身。數(shù)據(jù)源是全集當前頁是視圖這個邊界不能破。4. 服務端分頁的完整鏈路參數(shù)、loading、競態(tài)控制一次說清服務端分頁是實際業(yè)務中占比最高的形態(tài)因為它能真正解決大數(shù)據(jù)量場景下的性能瓶頸。我用一個訂單列表的案例來講透完整鏈路。4.1 請求參數(shù)的組裝服務端分頁的第一件事是把分頁參數(shù)傳給接口。View UI 的 Page 組件在頁碼變化時觸發(fā)on-change這個回調參數(shù)就是新的頁碼我們需要把它同步給后端。這里要注意字段名對齊的問題。不同后端團隊定義的分頁參數(shù)不一樣有的用pageNum、pageSize有的用page、limit還有的用current、size。建議前端在封裝請求層時統(tǒng)一做一層參數(shù)轉換不要在每個頁面里散落各種字段名。我在項目中通常這樣處理methods: { buildPageParams() { return { page: this.currentPage, // 頁碼從 1 開始 pageSize: this.pageSize, // 每頁條數(shù) // 其他查詢條件... keyword: this.keyword, status: this.status } }, async fetchOrderList() { this.loading true try { const params this.buildPageParams() const res await getOrderList(params) this.tableData res.data.records || [] this.total res.data.total } catch (error) { // 統(tǒng)一錯誤處理 this.$Message.error(訂單列表加載失敗) } finally { this.loading false } } }這里有個非常容易踩的坑接口返回的字段名不一致。有的后端返回{ list: [], totalCount: 100 }有的返回{ rows: [], total: 100 }還有的包裝成{ data: { records: [], total: 0 } }。建議把接口返回結構統(tǒng)一收斂到一個normalizeResponse方法里把字段名都轉換成語義明確的內(nèi)部結構。4.2 頁碼變化時的完整邏輯服務端分頁的handlePageChange不能像前端分頁那樣只更新一個頁碼變量它要觸發(fā)重新請求數(shù)據(jù)async handlePageChange(page) { if (page this.currentPage) return this.currentPage page await this.fetchOrderList() }這段代碼看似簡單實際生產(chǎn)環(huán)境里還會遇到更多情況我展開講三個我反復踩過的坑。4.3 競態(tài)問題快速翻頁時響應順序會錯亂這是我在真實項目中遇到的最隱蔽的 bug。用戶快速點擊下一頁、下一頁、下一頁前端會發(fā)出三個并發(fā)的異步請求。由于網(wǎng)絡延遲不同先發(fā)的請求未必先返回。如果最后一次點擊的響應先回來了把表格數(shù)據(jù)更新為第 3 頁的內(nèi)容但緊接著第一次點擊的響應才姍姍來遲又把表格覆蓋成第 1 頁的內(nèi)容——而此時的頁碼按鈕卻停留在第 3 頁。數(shù)據(jù)和頁碼錯位用戶看到的就是頁碼是 3表格內(nèi)容卻是第一頁的靈異現(xiàn)象。解決方式有幾種我推薦用一個簡單的請求序號標記methods: { async fetchOrderList() { const requestId this.requestSequence // 每次請求自增 this.loading true try { const res await getOrderList(this.buildPageParams()) // 如果已經(jīng)不是最新的請求直接丟棄這次結果 if (requestId ! this.requestSequence) return this.tableData res.data.records this.total res.data.total } finally { if (requestId this.requestSequence) { this.loading false } } } }原理就是每次請求前用一個自增序號標記這是第幾個請求當響應回來時如果當前的序號已經(jīng)不是自己發(fā)出的那次了說明有更新的請求已經(jīng)發(fā)出這次舊響應直接丟棄不再更新數(shù)據(jù)。這個方法比axios的CancelToken更輕量也不需要額外引入庫已經(jīng)足夠應對大部分業(yè)務場景。4.4 loading 狀態(tài)的正確打開方式服務端分頁必須處理 loading因為翻頁時有一段網(wǎng)絡空白期。不處理的話用戶翻頁后會看到表格內(nèi)容停留在舊數(shù)據(jù)上容易誤以為是不是自己點錯了。View UI 的 Table 組件自帶一個loading屬性傳入布爾值即可Table :columnscolumns :datatableData :loadingloading/Table翻頁的時候建議使用 Page 組件的on-change回調里第一時間把 loading 置為 true并在請求 finally 中置為 false。這樣可以保證翻頁交互期間表格上方出現(xiàn) loading 遮罩避免用戶誤操作。4.5 總數(shù)獲取與展示Page 組件的total屬性是數(shù)據(jù)總條數(shù)不是總頁數(shù)。它需要從接口返回的 total 字段中獲取。很多人初學時會犯一個錯誤把total設置為當頁返回的數(shù)據(jù)條數(shù)導致 Page 組件永遠只有一頁。這個坑我見得太多了必須單獨拎出來說。接口返回的 total 是服務端根據(jù)查詢條件統(tǒng)計出來的完整數(shù)據(jù)量Page 組件拿到 total 后自己會計算總頁數(shù)并在頁碼欄右側渲染出共 X 條的文字配合show-total屬性。5. 合并查詢條件的分頁搜索、頁碼重置、參數(shù)同步一個都不能少真實項目里表格分頁幾乎總是和搜索條件綁在一起的。這一章的坑比基礎分頁多得多值得單獨開一節(jié)來說。5.1 搜索時頁碼必須重置到第一頁這是一個看起來是小事、做錯了就是事故的點。假設用戶正在瀏覽第 8 頁的數(shù)據(jù)此時他在搜索框里輸入了新的關鍵詞點擊查詢按鈕。如果查詢邏輯只是簡單地把tableData重新賦值為新接口的返回結果而currentPage還停留在 8會出現(xiàn)兩種情況接口返回的是第 8 頁的數(shù)據(jù)但符合條件的數(shù)據(jù)總共可能只有 2 頁前端拿到的就是第 8 頁不存在的數(shù)據(jù)——往往是空數(shù)組。即使后端對超出總頁數(shù)的頁碼做了容錯返回最后一頁用戶體驗依然是混亂的我明明搜的是新關鍵詞為什么頁碼還停在第 8正確做法是搜索條件變化時把 currentPage 重置為 1同時把查詢參數(shù)傳給后端。handleSearch() { this.currentPage 1 this.fetchOrderList() }如果把搜索框和頁碼聯(lián)動封裝到一個統(tǒng)一的handleQuery方法里還可以進一步簡化handleQuery(resetPage true) { if (resetPage) { this.currentPage 1 } this.fetchOrderList() }5.2 查詢參數(shù)的深拷貝陷阱前端傳搜索條件給后端時如果直接把響應綁定的對象傳給請求函數(shù)這些參數(shù)對象其實是 Vue 的響應式代理內(nèi)部帶著各種 getter/setter。在序列化傳輸時某些情況下會出現(xiàn)參數(shù)丟失或附加多余字段的問題。具體表現(xiàn)是搜索條件明明在界面上看得見但后端收到的請求參數(shù)里卻沒有。這個坑在 axios 結合 Vue 2 的響應式系統(tǒng)時偶有發(fā)生排查起來非常隱蔽。我的建議是組裝請求參數(shù)時使用一個新對象buildPageParams() { return { page: this.currentPage, pageSize: this.pageSize, keyword: this.keyword ? this.keyword.trim() : , status: this.status, dateRange: this.dateRange ? [...this.dateRange] : [] } }不要直接把this.searchForm整個傳給請求函數(shù)而是手動選取需要的字段組裝新對象。這樣既避免了響應式代理的序列化坑也讓請求參數(shù)變得可控和可調試。5.3 搜索后頁碼是保留了但查詢參數(shù)對不上還有一種常見 bug搜索關鍵詞為 A結果用戶翻頁時把關鍵詞改成了 B然后點下一頁請求參數(shù)卻是關鍵詞 B 第 2 頁。如果后端不校驗頁碼和查詢條件組合的合法性就會返回一個混合結果。這個問題的根源在于頁碼和關鍵詞是兩個來源不同、更新時機不同的狀態(tài)。解決思路是在翻頁回調時確保用的是當前最新的查詢條件async handlePageChange(page) { this.currentPage page await this.fetchOrderList() }只要fetchOrderList每次讀取的是最新的this.keyword、this.status等數(shù)據(jù)而不是在搜索那一刻就拍扁的快照這個問題就不會出現(xiàn)。所以組裝請求參數(shù)時務必在請求方法內(nèi)動態(tài)讀取組件狀態(tài)而不是在某個初始化階段把參數(shù)固化下來。6. 邊界場景與真實事故復盤刪除、編輯后頁碼漂移怎么處理分頁代碼寫完之后考驗功力的是邊界場景。這部分內(nèi)容網(wǎng)上很難找到系統(tǒng)性總結大多是從一次次的線上問題里摸爬滾打出來的在這里一并分享。6.1 刪除當前頁最后一條數(shù)據(jù)后的頁碼回退假設當前是第 3 頁每頁 10 條這頁有 3 條數(shù)據(jù)。用戶刪掉了其中 2 條此時第 3 頁可能只剩下 1 條數(shù)據(jù)甚至刪掉最后一條后整頁變空。如果你只是簡單刷新當前頁表格很可能顯示暫無數(shù)據(jù)而實際上前面還有第 1、2 頁的數(shù)據(jù)。用戶會以為數(shù)據(jù)被刪光了實際上是被空頁給擋住了。我的經(jīng)驗是刪除后重新請求數(shù)據(jù)并且根據(jù)返回的總數(shù)判斷當前頁碼是否越界。更穩(wěn)妥的做法是先刪數(shù)據(jù)成功后重新請求總數(shù)如果當前頁的起始索引大于等于總數(shù)就把頁碼回退一頁。async handleDelete(row) { const success await deleteOrder(row.id) if (!success) return // 重新拉取數(shù)據(jù)判斷頁碼是否需要回退 await this.fetchOrderList() const maxPage Math.max(1, Math.ceil(this.total / this.pageSize)) if (this.currentPage maxPage) { this.currentPage maxPage await this.fetchOrderList() } }注意判斷條件是currentPage maxPage而不是簡單的total 0。因為可能出現(xiàn)當前頁 5 條刪了 1 條還剩 4 條的情況不需要回退但如果是當前頁最后一條被刪就必須往回退一頁否則用戶就看不到前面的數(shù)據(jù)了。6.2 編輯數(shù)據(jù)后必須當前頁碼重新拉取編輯場景和刪除不一樣用戶在第 2 頁編輯了一條數(shù)據(jù)保存后如果直接跳到第一頁重查用戶的閱讀位置就丟了體驗很糟糕。正確做法是停留在當前頁碼重新拉取數(shù)據(jù)。async handleEditSave(formData) { await updateOrder(formData) await this.fetchOrderList() // 保持 currentPage 不變 }這樣既刷新了表格內(nèi)容也保留了用戶的瀏覽位置。這里要特別提醒編輯成功后不要順手把 currentPage 重置為 1除非業(yè)務方明確要求編輯后回到第一頁。很多產(chǎn)品經(jīng)理不會明說這個細節(jié)但作為開發(fā)你要有判斷力。6.3 多 Tab 切換后分頁狀態(tài)的保持與重置如果頁面里用了 Tabs 組件每個 Tab 都是一個列表每個列表都有獨立的分頁狀態(tài)。這里有個微妙的設計取舍有的產(chǎn)品希望切換 Tab 后保留每個 Tab 的頁碼方便用戶回來繼續(xù)看。有的產(chǎn)品希望切換 Tab 后重置為第一頁認為用戶重新進入某個 Tab 就是一次新的瀏覽。我建議在data中為每個 Tab 維護獨立的分頁狀態(tài)而不是共用一個currentPagedata() { return { pagerMap: { tabA: { currentPage: 1, pageSize: 10, total: 0 }, tabB: { currentPage: 1, pageSize: 10, total: 0 } }, activeTab: tabA } }, computed: { activePager() { return this.pagerMap[this.activeTab] } }這樣每個 Tab 的頁碼互不干擾切換回來時用戶能回到原來的位置。滿足 保留瀏覽位置 這一體驗要求。6.4 Page 組件尺寸和顯示優(yōu)化的幾個細節(jié)View UI 的 Page 組件在業(yè)務中的使用頻率很高有幾個屬性配置建議直接借鑒show-total在左側顯示共 X 條比單獨放一行文字更直觀。show-elevator顯示跳頁輸入框數(shù)據(jù)量大、頁碼多時很有用。show-sizer顯示每頁條數(shù)選擇器讓用戶自主調整 pageSize。placement在有 show-sizer 且組件空間受限時可以通過 placement 控制 poptip 彈出方向。加上這些屬性后的基礎寫法Page :totaltotal :currentcurrentPage :page-sizepageSize show-total show-elevator show-sizer :page-size-opts[10, 20, 50, 100] on-changehandlePageChange on-page-size-changehandlePageSizeChange /6.5 pageSize 切換時也要回到第一頁當用戶通過 show-sizer 將每頁條數(shù)從 10 改成 50 時當前頁碼不能保持原樣。舉個例子用戶在 10 條/頁時停留在第 8 頁此時改成 50 條/頁第 8 頁其實只對應原來的第 5 頁左右數(shù)據(jù)內(nèi)容會完全錯位。必須把頁碼重置為 1 再重新查詢才能保證展示邏輯自洽handlePageSizeChange(newSize) { this.pageSize newSize this.currentPage 1 this.fetchOrderList() }7. 封裝一個通用分頁表格組件把重復勞動一次解決當一個項目里有十幾個列表頁都需要分頁時每次都復制粘貼currentPage、pageSize、total、loading、fetchXxx這五件套會非常痛苦。我在實際項目中會封裝一個通用組件PagedTable把 Table 和 Page 的組合邏輯收納進去業(yè)務頁面只關心怎么取數(shù)。7.1 組件設計思路組件的核心設計是讓父組件決定數(shù)據(jù)從哪來讓子組件統(tǒng)一管理分頁狀態(tài)和交互。我選擇用「傳入一個返回 Promise 的取數(shù)函數(shù) 查詢參數(shù)對象」這樣的組合方式template div classpaged-table Table :columnscolumns :datatableData :loadingloading v-bind$attrs / div classpaged-table__footer Page :totaltotal :currentcurrentPage :page-sizepageSize show-total show-elevator show-sizer :page-size-optspageSizeOpts on-changehandlePageChange on-page-size-changehandlePageSizeChange / /div /div /template組件的 props 可以這樣設計屬性名類型說明columnsArray表格列配置fetchDataFunction接收分頁參數(shù)返回 PromisequeryParamsObject查詢條件對象pageSizeNumber每頁條數(shù)默認 10pageSizeOptsArray可選的每頁條數(shù)列表immediateLoadBoolean是否創(chuàng)建時立即加載組件的核心邏輯要感知查詢參數(shù)的變化當父組件傳入的queryParams變化時自動重置頁碼并重新請求數(shù)據(jù)。這一步可以通過在組件內(nèi)監(jiān)聽watch: { queryParams: { deep: true, handler() { this.currentPage 1 this.loadTableData() } } }這里有個細節(jié)deep: true的成本不低如果項目中有大量這樣的組件同時監(jiān)聽對象會有性能壓力。我的做法是在業(yè)務頁面主動調用組件的reload()方法來替代深監(jiān)聽見下方的 7.3 小節(jié)。7.2 組件的完整邏輯實現(xiàn)下面是我在項目中使用過的完整PagedTable業(yè)務組件實現(xiàn)。它是一個「行為收斂」的封裝適用于基于 Promise 接口的中后臺 CRUD 列表場景。export default { name: PagedTable, props: { columns: { type: Array, required: true }, fetchData: { type: Function, required: true }, queryParams: { type: Object, default: () ({}) }, defaultPageSize: { type: Number, default: 10 }, pageSizeOpts: { type: Array, default: () [10, 20, 50, 100] }, immediateLoad: { type: Boolean, default: true } }, data() { return { tableData: [], total: 0, currentPage: 1, pageSize: this.defaultPageSize, loading: false, requestSequence: 0 } }, created() { if (this.immediateLoad) { this.loadTableData() } }, methods: { async loadTableData() { const requestId this.requestSequence this.loading true try { const res await this.fetchData({ page: this.currentPage, pageSize: this.pageSize, ...this.queryParams }) if (requestId ! this.requestSequence) return this.tableData res.records this.total res.total // 額外處理若當前頁已經(jīng)被刪空自動回退頁碼 if (this.tableData.length 0 this.currentPage 1) { this.currentPage - 1 return this.loadTableData() } } catch (e) { this.$Message.error(數(shù)據(jù)加載失敗) } finally { if (requestId this.requestSequence) { this.loading false } } }, handlePageChange(page) { this.currentPage page this.loadTableData() }, handlePageSizeChange(size) { this.pageSize size this.currentPage 1 this.loadTableData() }, reload() { this.loadTableData() }, reset() { this.currentPage 1 this.loadTableData() } } }在「當前頁已被刪空」的處理上我在前面 6.1 小節(jié)提到的是「刪除后判斷頁碼是否越界再回退」而封裝組件時我傾向于用更穩(wěn)的兜底策略如果接口返回的當前頁數(shù)據(jù)為空且當前頁碼大于 1就自動往前退一頁并重新加載。這樣即使是批量刪除、排序后行數(shù)變化、多端同時操作導致的數(shù)據(jù)量突變也能自動修正頁碼不會出現(xiàn)空白頁。7.3 父組件怎么用這個組件父組件里只需要把取數(shù)函數(shù)和查詢條件對象傳進去template div div classfilter-bar Input v-modelkeyword placeholder搜索訂單號 clearable on-enterhandleSearch / Button typeprimary clickhandleSearch查詢/Button /div PagedTable refpagedTable :columnscolumns :fetch-datafetchOrderList :query-params{ keyword, status } / /div /template script import PagedTable from /components/PagedTable export default { components: { PagedTable }, methods: { // 注意這個函數(shù)要保證 this 正確返回 { records, total } fetchOrderList({ page, pageSize, ...rest }) { return getOrderList({ page, pageSize, ...rest }) }, handleSearch() { this.$refs.pagedTable.reset() } } } /script這樣封裝的好處是業(yè)務頁面不再需要關心 currentPage、total、loading 這些狀態(tài)只需要關注接口怎么調、列怎么配。當項目里列表變多時這種封裝的復利效應會非常明顯。不過要注意封裝組件不要過度設計。如果你的項目只有兩個列表頁硬套這個組件反而增加了理解和維護成本。我在實際項目中通常先在兩個頁面里跑通這種寫法覺得順了再抽成組件屬于先重復再抽象的節(jié)奏。8. 實測中容易忽略的性能與體驗細節(jié)代碼能跑通只是第一步線上體驗才是分頁的真正考場。這一章集中講我實測中重點注意的幾處性能與交互細節(jié)。8.1 大數(shù)據(jù)量下避免一次性渲染過多表格行即使走了服務端分頁如果 pageSize 設置成 100 甚至更大Table 要在一幀內(nèi)渲染 100 行乘以若干列的 DOM在低端設備上依然會產(chǎn)生明顯的白屏。比如你的報表頁允許用戶選擇每頁 200 條在移動端或者性能一般的電腦上視覺上會感覺點了翻頁之后卡了半秒多。我建議開發(fā)階段做一次性能壓測打開瀏覽器的 Performance 面板把 pageSize 調到 100連續(xù)快速切換 5 頁觀察每一幀的耗時。如果 Long Task 超過 100ms就需要考慮控制 pageSize 上限比如最高 100或者引導用戶使用更高粒度的過濾條件來縮小結果集。8.2 快速翻頁時的節(jié)流策略前面 4.3 節(jié)用 requestSequence 解決了響應順序錯亂的問題但如果你連頻繁點擊翻頁都不希望發(fā)生前端可以再加一層節(jié)流。最簡單的方式是在handlePageChange里加一個時間鎖handlePageChange(page) { if (this.isFetching) return this.currentPage page this.loadTableData() }在loadTableData開始和結束的地方分別把isFetching置為 true 和 false這樣在請求未返回時用戶點擊任何頁碼都會被忽略。這在操作頻繁的管理后臺里非常實用能顯著降低后端請求壓力。8.3 頁碼變化但總分頁數(shù)為 1 時的 UI 處理如果接口返回的 total 本來就是小于等于 pageSize 的值Page 組件會渲染出 1 頁。這沒問題但如果同時開啟了 show-sizer用戶把 pageSize 改大后total 可能依然不變。要注意 Page 組件的 total 始終是符合條件的總條數(shù)而不是當前頁的總數(shù)?？倵l數(shù)不會因為改 pageSize 而變化的。另外total 是提前知道還是請求返回才知道在服務端分頁中首次請求前 total 為空Page 組件渲染出來是空的這會造成一點布局抖動。如果對布局穩(wěn)定性有要求可以給 Page 組件加一個初始 total 為 0并在 table 外層容器給一個最小高度。8.4 空數(shù)據(jù) vs 總數(shù)為 0 的文案區(qū)分表格數(shù)據(jù)為空時View UI 的 Table 默認顯示暫無數(shù)據(jù)。但如果 total 為 0 且當前頁為 1屬于正?？諔B(tài)如果 total 大于 0 但當前頁數(shù)據(jù)為空說明頁碼越界或存在臟數(shù)據(jù)。這兩種情況要分開處理正?？諔B(tài)保持暫無數(shù)據(jù)不需要任何操作。頁碼越界空態(tài)觸發(fā)頁碼回退邏輯如第 7 章組件中的兜底策略并建議在控制臺打印一條日志方便排查是哪個環(huán)節(jié)造成的越界。我之前排查過一個線上問題某個訂單列表在切換 Tab 后偶爾出現(xiàn)空白頁就是Tab 切換后保留了當前第 8 頁的頁碼但新 Tab 的數(shù)據(jù)總量只有 3 頁導致的。加上頁碼回退邏輯后問題直接消失。9. 最后再分享兩個小技巧第一個技巧關于請求參數(shù)的調試。服務端分頁的交互鏈路長定位問題時要學會用 curl 復現(xiàn) 的方法。在 Chrome 的 Network 面板里拿到分頁請求的完整 URL然后復制成 curl 命令在終端執(zhí)行看響應結構。這比在代碼里打斷點更直接能快速分清是前端參數(shù)問題還是后端返回問題。第二個技巧關于 Table 組件的行高一致性。分頁后表格每頁的渲染高度可能不同翻頁時頁面會出現(xiàn)跳動。可以在 Table 外層設置一個固定最小高度比如把數(shù)據(jù)區(qū)域的 min-height 定為(pageSize 1) * 行高這樣翻頁時頁面不會突然變矮或變高。這個細節(jié)在小屏幕終端上特別明顯值得為它做一次適配。分頁這個功能說難不難說簡單也絕不簡單。核心還是想清楚數(shù)據(jù)流的來源與出口把前端展示狀態(tài)和服務端數(shù)據(jù)請求的邊界理干凈。配合 View UI 的 Table 和 Page 組件只要把頁碼狀態(tài)、查詢參數(shù)、請求競態(tài)、邊界兜底這四件事處理扎實線上的分頁體驗基本就能穩(wěn)住。希望這篇分享能幫你少踩幾個坑。