避坑指南)
3步搞定分頁符怎么插入，手寫實現(xiàn)避坑指南
版本升級后 API 全變了，原本一行代碼能搞定的排版功能，現(xiàn)在直接報錯。別慌，這就是為什么你需要理解底層邏輯，而不是只會調(diào)用庫函數(shù)。今天咱們不整虛的，直接拆解分頁符怎么插入的底層原理，通過手寫實現(xiàn)一個最小化的分頁引擎，讓你徹底搞懂?dāng)?shù)據(jù)在內(nèi)存中是如何被切割、組裝并輸出到瀏覽器或打印機的。
很多人以為分頁只是前端加個 page-break 或者后端切個數(shù)組，其實這背后涉及復(fù)雜的流式數(shù)據(jù)處理、狀態(tài)同步和渲染邊界控制。如果你在掘金技術(shù)社區(qū)刷過前端渲染相關(guān)的文章，會發(fā)現(xiàn)很多性能瓶頸都出在長列表的分頁渲染上。今天這篇文章，就是為你準備的“祛魅”指南，從原理到代碼，手把手帶你實現(xiàn)一個穩(wěn)健的分頁插入機制。
1. 一句話原理：流式數(shù)據(jù)的“斷句”藝術(shù)
分頁的本質(zhì)，不是“把數(shù)據(jù)切開”，而是在數(shù)據(jù)流的傳輸或渲染過程中，基于特定條件（如行數(shù)、容量、視覺邊界）進行的邏輯斷句。
想象你在讀一本沒有頁碼的書，你每隔50行就要抬頭看一次，這就是你的“分頁符”。在計算機系統(tǒng)中，分頁符（Page Break）是一個隱式的信號，告訴系統(tǒng)：“嘿，前面的內(nèi)容已經(jīng)裝滿一個‘容器’（頁面/緩沖區(qū)）了，剩下的內(nèi)容請放到下一個容器里?！?對于前端而言，這個容器是視口（Viewport）或虛擬列表的渲染塊；對于后端或數(shù)據(jù)庫而言，這個容器是查詢結(jié)果集的分片（Chunk）；對于打印引擎而言，這個容器是物理紙張的A4區(qū)域。理解了這個“斷句”概念，你就明白了為什么有時候分頁會導(dǎo)致數(shù)據(jù)丟失，或者為什么翻頁時會出現(xiàn)白屏——因為你的“斷句”位置選錯了，或者“斷句”后的銜接邏輯斷了。
2. 類比解釋：快遞打包與分倉發(fā)貨
為了更直觀地理解，我們把“數(shù)據(jù)”比作“商品”，把“頁面”比作“快遞箱”。
假設(shè)你有一個倉庫（數(shù)據(jù)庫/內(nèi)存），里面堆滿了1000件商品（數(shù)據(jù)行）。快遞員（瀏覽器/打印機）一次只能搬走10件商品（每頁10條數(shù)據(jù)）。
傳統(tǒng)API調(diào)用模式就像你直接告訴快遞員：“幫我搬第一箱?！笨爝f員去倉庫，數(shù)出10件，打包，搬走。這時候你不需要知道倉庫怎么管理的，你只需要調(diào)用 fetchPage(1)。
手寫實現(xiàn)模式則是你自己當(dāng)倉庫管理員。你需要知道：掃描：從第1件開始掃，掃到第10件時，打上一個“封箱標記”（插入分頁符）。
狀態(tài)記錄：記住當(dāng)前掃到了第10件，下一批從第11件開始。
異常處理：如果第5件商品突然壞了（數(shù)據(jù)校驗失敗），你是跳過它繼續(xù)數(shù)，還是讓這一箱作廢？很多開發(fā)者在版本升級后遇到 API 變更，往往是因為新版庫底層改變了“封箱”的時機。比如舊版是“先取滿10件再封箱”，新版可能是“每取1件就檢查是否夠10件，夠了就封箱”。這種細微的邏輯差異，如果不懂底層，你就只能盲目猜測參數(shù)，導(dǎo)致 Bug 頻發(fā)。
3. 源碼/偽代碼片段：手寫一個極簡分頁引擎
為了講透原理，我們不依賴任何 UI 框架，直接用 JavaScript 手寫一個核心的分頁插入邏輯。這段代碼模擬了后端返回數(shù)據(jù)流，前端進行“斷句”并插入分頁符的過程。
/*** 極簡分頁引擎：手寫實現(xiàn)分頁符插入* @param {Array} rawData - 原始數(shù)據(jù)數(shù)組* @param {Number} pageSize - 每頁顯示條數(shù)* @param {Function} renderPage - 渲染單頁數(shù)據(jù)的回調(diào)* @param {Function} insertPageBreak - 插入分頁符的回調(diào)（模擬DOM操作或打印指令）*/
function handWrittenPagination(rawData, pageSize, renderPage, insertPageBreak) {if (!Array.isArray(rawData) || rawData.length === 0) {console.warn(無數(shù)據(jù)可分頁);return;}const totalPages = Math.ceil(rawData.length / pageSize);// 核心邏輯：遍歷所有頁，手動切割并插入標記for (let pageIndex = 0; pageIndex totalPages; pageIndex++) {// 1. 計算當(dāng)前頁的起始索引和結(jié)束索引const start = pageIndex * pageSize;const end = Math.min(start + pageSize, rawData.length);// 2. 切片：獲取當(dāng)前頁的數(shù)據(jù)片段// 注意：這里 slice 是淺拷貝，如果數(shù)據(jù)對象復(fù)雜，需注意引用問題const currentPageData = rawData.slice(start, end);// 3. 模擬插入分頁符// 在實際場景中，這里可能是 document.createElement('div').className = 'page-break'// 或者在打印時調(diào)用 window.print() 前的 CSS @media print { .page-break { page-break-after: always; } }if (pageIndex 0) {insertPageBreak({position: 'after',pageIndex: pageIndex - 1,reason: 'Capacity Full' // 斷句原因：容量已滿});}// 4. 渲染當(dāng)前頁數(shù)據(jù)// 在實際開發(fā)中，這里會觸發(fā) React/Vue 的更新，或者直接操作 DOMrenderPage(currentPageData, {page: pageIndex + 1,total: totalPages,start: start,end: end});}
}// 模擬測試
const mockData = Array.from({ length: 25 }, (_, i) = ({ id: i + 1, value: `Item-${i + 1}` }));handWrittenPagination(mockData,10, // 每頁10條(data, meta) = {console.log(`--- 第 ${meta.page} 頁 ---`);console.log(`范圍: ${meta.start} - ${meta.end}`);console.log(data.map(d = d.value).join(', '));},(breakInfo) = {console.log(` [分頁符插入] 位置: 第 ${breakInfo.pageIndex} 頁后, 原因: ${breakInfo.reason}`);}
);逐行解析關(guān)鍵點：Math.ceil(rawData.length / pageSize)：這是計算總頁數(shù)最穩(wěn)妥的方式。很多人用 length / pageSize 忘記向上取整，導(dǎo)致最后一頁數(shù)據(jù)少于 pageSize 時，最后一頁不顯示。
rawData.slice(start, end)：slice 返回的是新數(shù)組，保證了數(shù)據(jù)隔離。如果直接引用原數(shù)組片段，修改某頁數(shù)據(jù)可能會意外影響其他頁，這是典型的狀態(tài)污染陷阱。
if (pageIndex 0)：注意，第一頁之前不需要插入分頁符。分頁符是“分隔線”，不是“起始線”。這個細節(jié)在 CSS 打印布局中經(jīng)常導(dǎo)致第一頁出現(xiàn)多余的空白頁。
insertPageBreak 的時機：我們在渲染當(dāng)前頁之前插入上一頁的分隔符。這符合“先斷句，再續(xù)寫”的邏輯。如果在渲染后插入，可能會導(dǎo)致瀏覽器重繪時布局抖動。4. 流程描述：從數(shù)據(jù)流到視覺呈現(xiàn)的完整鏈路
為了更清晰地展示分頁符在系統(tǒng)中的流轉(zhuǎn)，我們用文字流程描述一下整個過程，這有助于你在排查 Bug 時定位問題出在哪個環(huán)節(jié)。
graph TDA[原始數(shù)據(jù)源: DB/API/Memory] --> B{數(shù)據(jù)加載完成?}B -- 否 --> C[顯示 Loading 骨架屏]C --> BB -- 是 --> D[計算總頁數(shù) TotalPages]D --> E[初始化頁碼指針 PageIndex = 0]E --> F{PageIndex TotalPages?}F -- 否 --> G[分頁流程結(jié)束]F -- 是 --> H[計算 Start/End 索引]H --> I[Slice 切片獲取當(dāng)前頁數(shù)據(jù)]I --> J{是否為第一頁?}J -- 是 --> K[直接渲染數(shù)據(jù)]J -- 否 --> L[插入分頁符 PageBreak]L --> KK --> M[觸發(fā) DOM 更新/重繪]M --> N[更新 PageIndex++]N --> F流程中的三個隱形陷阱：數(shù)據(jù)異步到達的競態(tài)條件：如果數(shù)據(jù)是從 API 異步加載的，而用戶在數(shù)據(jù)還沒完全加載完時就瘋狂點擊“下一頁”，你的 PageIndex 可能會跑在數(shù)據(jù)前面，導(dǎo)致渲染出 undefined。手寫實現(xiàn)的優(yōu)勢在于，你可以在流程的 B 節(jié)點（數(shù)據(jù)加載完成?）加上鎖機制，確保數(shù)據(jù)就緒后再啟動分頁流程。
索引越界：在 H 步驟計算 End 索引時，必須使用 Math.min(start + pageSize, rawData.length)。如果直接用 start + pageSize，當(dāng)數(shù)據(jù)總量不能被 pageSize 整除時，最后一頁的 slice 會返回空數(shù)組，導(dǎo)致頁面空白。
分頁符的視覺累積：在長列表滾動場景中，如果每次滾動都插入新的分頁符節(jié)點而不銷毀舊的，DOM 節(jié)點會無限膨脹，最終導(dǎo)致瀏覽器卡頓。這就是為什么現(xiàn)代虛擬列表（Virtual List）通常不使用真實的 DOM 分頁符，而是通過計算偏移量（Offset）來模擬分頁效果。5. 實戰(zhàn)驗證與進階避坑指南
理論講完了，咱們回到現(xiàn)實場景。在掘金技術(shù)社區(qū)的很多高性能列表討論中，大家常提到的“虛擬分頁”其實就是對手動分頁邏輯的極致優(yōu)化。
場景一：打印時的分頁符
很多后臺管理系統(tǒng)需要打印報表。直接調(diào)用 window.print() 往往會出現(xiàn)表格截斷、頁眉頁腳錯位的問題。
避坑技巧：
不要依賴瀏覽器的自動分頁。使用 CSS 的 @page 規(guī)則定義紙張大小，并在每一頁數(shù)據(jù)的末尾手動插入一個帶有 page-break-after: always; 樣式的 div。
@media print {.report-page {page-break-after: always;height: 277mm; /* A4 紙減去頁邊距后的高度 */overflow: hidden;}
}注意：這里的 height 需要根據(jù)實際打印紙張和瀏覽器默認邊距精確計算。不同瀏覽器的默認邊距不同，建議讓用戶在打印預(yù)覽中確認，或者使用 @page { size: A4; margin: 0; } 強制歸零邊距后，手動控制內(nèi)邊距。
場景二：長列表的無限滾動（Infinite Scroll）
無限滾動其實是“懶加載分頁”的變體。它不是真的“無限”，而是當(dāng)用戶滾動到底部時，觸發(fā)“下一頁”的數(shù)據(jù)加載。
避坑技巧：防抖（Debounce）：滾動事件觸發(fā)頻率極高，必須在 scroll 事件上加防抖或節(jié)流，否則請求會像洪水一樣涌向服務(wù)器。
占位符高度：在數(shù)據(jù)加載期間，必須保持列表底部有一個固定高度的占位符，否則列表高度塌陷，觸發(fā) scrollTo 會導(dǎo)致頁面抖動。
去重：如果用戶快速滑動，可能會觸發(fā)多次加載。必須在內(nèi)存中維護一個 loadedIds 集合，在渲染前過濾掉已存在的數(shù)據(jù)，防止重復(fù)渲染。場景三：數(shù)據(jù)庫分頁的性能陷阱
當(dāng)數(shù)據(jù)量達到千萬級時，LIMIT offset, count 這種傳統(tǒng)的 SQL 分頁會變得極慢，因為數(shù)據(jù)庫需要掃描前 offset 行然后丟棄它們。
避坑技巧：
使用游標分頁（Cursor-based Pagination）。不再傳遞 page=100，而是傳遞 last_id=10000。SQL 查詢變?yōu)?SELECT * FROM table WHERE id 10000 ORDER BY id ASC LIMIT 10。這種方式利用索引，性能穩(wěn)定，不會隨頁碼增加而衰減。這也是為什么很多大型 API（如 Twitter API, GitHub API）使用 cursor 而不是 page 的原因。
總結(jié)與互動
通過手寫實現(xiàn)分頁邏輯，我們剝離了框架的黑盒，看到了數(shù)據(jù)流動的真實脈絡(luò)。分頁符不僅僅是一個符號，它是數(shù)據(jù)完整性、渲染性能和用戶體驗之間的平衡點。
版本升級后 API 全變了不可怕，可怕的是你不懂它為什么變。當(dāng)你理解了底層的“斷句”邏輯，你就能在任何新的框架或庫中，快速找到對應(yīng)的配置項，甚至自己封裝一個更穩(wěn)定的分頁工具。
技術(shù)沒有銀彈，只有更懂業(yè)務(wù)的代碼。你在項目中遇到過哪些奇葩的分頁 Bug？比如打印時最后一頁空白，或者滾動時數(shù)據(jù)重復(fù)？
還有什么不懂的?評論區(qū)留言挨個回 3步搞定分頁符怎么插入，手寫實現(xiàn)避坑指南
3步搞定分頁符怎么插入，手寫實現(xiàn)避坑指南
版本升級后 API 全變了，原本一行代碼能搞定的排版功能，現(xiàn)在直接報錯。別慌，這就是為什么你需要理解底層邏輯，而不是只會調(diào)用庫函數(shù)。今天咱們不整虛的，直接拆解分頁符怎么插入的底層原理，通過手寫實現(xiàn)一個最小化的分頁引擎，讓你徹底搞懂?dāng)?shù)據(jù)在內(nèi)存中是如何被切割、組裝并輸出到瀏覽器或打印機的。
很多人以為分頁只是前端加個 page-break 或者后端切個數(shù)組，其實這背后涉及復(fù)雜的流式數(shù)據(jù)處理、狀態(tài)同步和渲染邊界控制。如果你在掘金技術(shù)社區(qū)刷過前端渲染相關(guān)的文章，會發(fā)現(xiàn)很多性能瓶頸都出在長列表的分頁渲染上。今天這篇文章，就是為你準備的“祛魅”指南，從原理到代碼，手把手帶你實現(xiàn)一個穩(wěn)健的分頁插入機制。
1. 一句話原理：流式數(shù)據(jù)的“斷句”藝術(shù)
分頁的本質(zhì)，不是“把數(shù)據(jù)切開”，而是在數(shù)據(jù)流的傳輸或渲染過程中，基于特定條件（如行數(shù)、容量、視覺邊界）進行的邏輯斷句。
想象你在讀一本沒有頁碼的書，你每隔50行就要抬頭看一次，這就是你的“分頁符”。在計算機系統(tǒng)中，分頁符（Page Break）是一個隱式的信號，告訴系統(tǒng)：“嘿，前面的內(nèi)容已經(jīng)裝滿一個‘容器’（頁面/緩沖區(qū)）了，剩下的內(nèi)容請放到下一個容器里?！?對于前端而言，這個容器是視口（Viewport）或虛擬列表的渲染塊；對于后端或數(shù)據(jù)庫而言，這個容器是查詢結(jié)果集的分片（Chunk）；對于打印引擎而言，這個容器是物理紙張的A4區(qū)域。理解了這個“斷句”概念，你就明白了為什么有時候分頁會導(dǎo)致數(shù)據(jù)丟失，或者為什么翻頁時會出現(xiàn)白屏——因為你的“斷句”位置選錯了，或者“斷句”后的銜接邏輯斷了。
2. 類比解釋：快遞打包與分倉發(fā)貨
為了更直觀地理解，我們把“數(shù)據(jù)”比作“商品”，把“頁面”比作“快遞箱”。
假設(shè)你有一個倉庫（數(shù)據(jù)庫/內(nèi)存），里面堆滿了1000件商品（數(shù)據(jù)行）。快遞員（瀏覽器/打印機）一次只能搬走10件商品（每頁10條數(shù)據(jù)）。
傳統(tǒng)API調(diào)用模式就像你直接告訴快遞員：“幫我搬第一箱?！笨爝f員去倉庫，數(shù)出10件，打包，搬走。這時候你不需要知道倉庫怎么管理的，你只需要調(diào)用 fetchPage(1)。
手寫實現(xiàn)模式則是你自己當(dāng)倉庫管理員。你需要知道：掃描：從第1件開始掃，掃到第10件時，打上一個“封箱標記”（插入分頁符）。
狀態(tài)記錄：記住當(dāng)前掃到了第10件，下一批從第11件開始。
異常處理：如果第5件商品突然壞了（數(shù)據(jù)校驗失敗），你是跳過它繼續(xù)數(shù)，還是讓這一箱作廢？很多開發(fā)者在版本升級后遇到 API 變更，往往是因為新版庫底層改變了“封箱”的時機。比如舊版是“先取滿10件再封箱”，新版可能是“每取1件就檢查是否夠10件，夠了就封箱”。這種細微的邏輯差異，如果不懂底層，你就只能盲目猜測參數(shù)，導(dǎo)致 Bug 頻發(fā)。
3. 源碼/偽代碼片段：手寫一個極簡分頁引擎
為了講透原理，我們不依賴任何 UI 框架，直接用 JavaScript 手寫一個核心的分頁插入邏輯。這段代碼模擬了后端返回數(shù)據(jù)流，前端進行“斷句”并插入分頁符的過程。
/*** 極簡分頁引擎：手寫實現(xiàn)分頁符插入* @param {Array} rawData - 原始數(shù)據(jù)數(shù)組* @param {Number} pageSize - 每頁顯示條數(shù)* @param {Function} renderPage - 渲染單頁數(shù)據(jù)的回調(diào)* @param {Function} insertPageBreak - 插入分頁符的回調(diào)（模擬DOM操作或打印指令）*/
function handWrittenPagination(rawData, pageSize, renderPage, insertPageBreak) {if (!Array.isArray(rawData) || rawData.length === 0) {console.warn(無數(shù)據(jù)可分頁);return;}const totalPages = Math.ceil(rawData.length / pageSize);// 核心邏輯：遍歷所有頁，手動切割并插入標記for (let pageIndex = 0; pageIndex totalPages; pageIndex++) {// 1. 計算當(dāng)前頁的起始索引和結(jié)束索引const start = pageIndex * pageSize;const end = Math.min(start + pageSize, rawData.length);// 2. 切片：獲取當(dāng)前頁的數(shù)據(jù)片段// 注意：這里 slice 是淺拷貝，如果數(shù)據(jù)對象復(fù)雜，需注意引用問題const currentPageData = rawData.slice(start, end);// 3. 模擬插入分頁符// 在實際場景中，這里可能是 document.createElement('div').className = 'page-break'// 或者在打印時調(diào)用 window.print() 前的 CSS @media print { .page-break { page-break-after: always; } }if (pageIndex 0) {insertPageBreak({position: 'after',pageIndex: pageIndex - 1,reason: 'Capacity Full' // 斷句原因：容量已滿});}// 4. 渲染當(dāng)前頁數(shù)據(jù)// 在實際開發(fā)中，這里會觸發(fā) React/Vue 的更新，或者直接操作 DOMrenderPage(currentPageData, {page: pageIndex + 1,total: totalPages,start: start,end: end});}
}// 模擬測試
const mockData = Array.from({ length: 25 }, (_, i) = ({ id: i + 1, value: `Item-${i + 1}` }));handWrittenPagination(mockData,10, // 每頁10條(data, meta) = {console.log(`--- 第 ${meta.page} 頁 ---`);console.log(`范圍: ${meta.start} - ${meta.end}`);console.log(data.map(d = d.value).join(', '));},(breakInfo) = {console.log(` [分頁符插入] 位置: 第 ${breakInfo.pageIndex} 頁后, 原因: ${breakInfo.reason}`);}
);逐行解析關(guān)鍵點：Math.ceil(rawData.length / pageSize)：這是計算總頁數(shù)最穩(wěn)妥的方式。很多人用 length / pageSize 忘記向上取整，導(dǎo)致最后一頁數(shù)據(jù)少于 pageSize 時，最后一頁不顯示。
rawData.slice(start, end)：slice 返回的是新數(shù)組，保證了數(shù)據(jù)隔離。如果直接引用原數(shù)組片段，修改某頁數(shù)據(jù)可能會意外影響其他頁，這是典型的狀態(tài)污染陷阱。
if (pageIndex 0)：注意，第一頁之前不需要插入分頁符。分頁符是“分隔線”，不是“起始線”。這個細節(jié)在 CSS 打印布局中經(jīng)常導(dǎo)致第一頁出現(xiàn)多余的空白頁。
insertPageBreak 的時機：我們在渲染當(dāng)前頁之前插入上一頁的分隔符。這符合“先斷句，再續(xù)寫”的邏輯。如果在渲染后插入，可能會導(dǎo)致瀏覽器重繪時布局抖動。4. 流程描述：從數(shù)據(jù)流到視覺呈現(xiàn)的完整鏈路
為了更清晰地展示分頁符在系統(tǒng)中的流轉(zhuǎn)，我們用文字流程描述一下整個過程，這有助于你在排查 Bug 時定位問題出在哪個環(huán)節(jié)。
graph TDA[原始數(shù)據(jù)源: DB/API/Memory] --> B{數(shù)據(jù)加載完成?}B -- 否 --> C[顯示 Loading 骨架屏]C --> BB -- 是 --> D[計算總頁數(shù) TotalPages]D --> E[初始化頁碼指針 PageIndex = 0]E --> F{PageIndex TotalPages?}F -- 否 --> G[分頁流程結(jié)束]F -- 是 --> H[計算 Start/End 索引]H --> I[Slice 切片獲取當(dāng)前頁數(shù)據(jù)]I --> J{是否為第一頁?}J -- 是 --> K[直接渲染數(shù)據(jù)]J -- 否 --> L[插入分頁符 PageBreak]L --> KK --> M[觸發(fā) DOM 更新/重繪]M --> N[更新 PageIndex++]N --> F流程中的三個隱形陷阱：數(shù)據(jù)異步到達的競態(tài)條件：如果數(shù)據(jù)是從 API 異步加載的，而用戶在數(shù)據(jù)還沒完全加載完時就瘋狂點擊“下一頁”，你的 PageIndex 可能會跑在數(shù)據(jù)前面，導(dǎo)致渲染出 undefined。手寫實現(xiàn)的優(yōu)勢在于，你可以在流程的 B 節(jié)點（數(shù)據(jù)加載完成?）加上鎖機制，確保數(shù)據(jù)就緒后再啟動分頁流程。
索引越界：在 H 步驟計算 End 索引時，必須使用 Math.min(start + pageSize, rawData.length)。如果直接用 start + pageSize，當(dāng)數(shù)據(jù)總量不能被 pageSize 整除時，最后一頁的 slice 會返回空數(shù)組，導(dǎo)致頁面空白。
分頁符的視覺累積：在長列表滾動場景中，如果每次滾動都插入新的分頁符節(jié)點而不銷毀舊的，DOM 節(jié)點會無限膨脹，最終導(dǎo)致瀏覽器卡頓。這就是為什么現(xiàn)代虛擬列表（Virtual List）通常不使用真實的 DOM 分頁符，而是通過計算偏移量（Offset）來模擬分頁效果。5. 實戰(zhàn)驗證與進階避坑指南
理論講完了，咱們回到現(xiàn)實場景。在掘金技術(shù)社區(qū)的很多高性能列表討論中，大家常提到的“虛擬分頁”其實就是對手動分頁邏輯的極致優(yōu)化。
場景一：打印時的分頁符
很多后臺管理系統(tǒng)需要打印報表。直接調(diào)用 window.print() 往往會出現(xiàn)表格截斷、頁眉頁腳錯位的問題。
避坑技巧：
不要依賴瀏覽器的自動分頁。使用 CSS 的 @page 規(guī)則定義紙張大小，并在每一頁數(shù)據(jù)的末尾手動插入一個帶有 page-break-after: always; 樣式的 div。
@media print {.report-page {page-break-after: always;height: 277mm; /* A4 紙減去頁邊距后的高度 */overflow: hidden;}
}注意：這里的 height 需要根據(jù)實際打印紙張和瀏覽器默認邊距精確計算。不同瀏覽器的默認邊距不同，建議讓用戶在打印預(yù)覽中確認，或者使用 @page { size: A4; margin: 0; } 強制歸零邊距后，手動控制內(nèi)邊距。
場景二：長列表的無限滾動（Infinite Scroll）
無限滾動其實是“懶加載分頁”的變體。它不是真的“無限”，而是當(dāng)用戶滾動到底部時，觸發(fā)“下一頁”的數(shù)據(jù)加載。
避坑技巧：防抖（Debounce）：滾動事件觸發(fā)頻率極高，必須在 scroll 事件上加防抖或節(jié)流，否則請求會像洪水一樣涌向服務(wù)器。
占位符高度：在數(shù)據(jù)加載期間，必須保持列表底部有一個固定高度的占位符，否則列表高度塌陷，觸發(fā) scrollTo 會導(dǎo)致頁面抖動。
去重：如果用戶快速滑動，可能會觸發(fā)多次加載。必須在內(nèi)存中維護一個 loadedIds 集合，在渲染前過濾掉已存在的數(shù)據(jù)，防止重復(fù)渲染。場景三：數(shù)據(jù)庫分頁的性能陷阱
當(dāng)數(shù)據(jù)量達到千萬級時，LIMIT offset, count 這種傳統(tǒng)的 SQL 分頁會變得極慢，因為數(shù)據(jù)庫需要掃描前 offset 行然后丟棄它們。
避坑技巧：
使用游標分頁（Cursor-based Pagination）。不再傳遞 page=100，而是傳遞 last_id=10000。SQL 查詢變?yōu)?SELECT * FROM table WHERE id 10000 ORDER BY id ASC LIMIT 10。這種方式利用索引，性能穩(wěn)定，不會隨頁碼增加而衰減。這也是為什么很多大型 API（如 Twitter API, GitHub API）使用 cursor 而不是 page 的原因。
總結(jié)與互動
通過手寫實現(xiàn)分頁邏輯，我們剝離了框架的黑盒，看到了數(shù)據(jù)流動的真實脈絡(luò)。分頁符不僅僅是一個符號，它是數(shù)據(jù)完整性、渲染性能和用戶體驗之間的平衡點。
版本升級后 API 全變了不可怕，可怕的是你不懂它為什么變。當(dāng)你理解了底層的“斷句”邏輯，你就能在任何新的框架或庫中，快速找到對應(yīng)的配置項，甚至自己封裝一個更穩(wěn)定的分頁工具。
技術(shù)沒有銀彈，只有更懂業(yè)務(wù)的代碼。你在項目中遇到過哪些奇葩的分頁 Bug？比如打印時最后一頁空白，或者滾動時數(shù)據(jù)重復(fù)？
還有什么不懂的?評論區(qū)留言挨個回