后端分頁(yè)藏了3個(gè)陷阱，第2個(gè)讓抖音工程師栽過(guò)跟頭

面試時(shí)背過(guò)"偏移量分頁(yè) vs 游標(biāo)分頁(yè)"的人，80%在生產(chǎn)環(huán)境踩過(guò)坑。不是概念沒(méi)懂，是不知道哪道題會(huì)考。

作者最近接了個(gè)無(wú)限滾動(dòng)+虛擬列表的需求，把分頁(yè)從"面試八股"變成了"線上決策"。這篇是他復(fù)盤后的完整筆記——包括那個(gè)讓列表漏項(xiàng)的經(jīng)典場(chǎng)景。

偏移量分頁(yè)：像翻紙質(zhì)書，但書頁(yè)會(huì)自己變

客戶端告訴服務(wù)器："跳過(guò)前40條，給我接下來(lái)的20條。"

服務(wù)器端的實(shí)現(xiàn)簡(jiǎn)單到像切數(shù)組：ALL_POSTS.slice(40, 60)。前端維護(hù)一個(gè)累加的offset，每次請(qǐng)求往上加20。知道什么時(shí)候停？服務(wù)器返回total總數(shù)，客戶端比對(duì)當(dāng)前已加載長(zhǎng)度就行。

這套機(jī)制用了幾十年，直到數(shù)據(jù)開(kāi)始流動(dòng)。

想象一個(gè)10個(gè)商品的列表。你正在看第1頁(yè)（商品1-10），這時(shí)候商品5被刪了。列表變成[1,2,3,4,6,7,8,9,10,11]。你翻頁(yè)請(qǐng)求offset=10，服務(wù)器跳過(guò)前10個(gè)——現(xiàn)在前10個(gè)是1,2,3,4,6,7,8,9,10,11——于是你從商品11開(kāi)始返回。

商品6永遠(yuǎn)消失了。不是被刪的，是被分頁(yè)邏輯吞掉的。

這就是"跳過(guò)項(xiàng)問(wèn)題"（Skipped Item Problem）：偏移量分頁(yè)在動(dòng)態(tài)數(shù)據(jù)下會(huì)漏項(xiàng)或重復(fù)。數(shù)據(jù)插入、刪除、排序變化時(shí)，offset的數(shù)學(xué)假設(shè)就失效了。

更隱蔽的是性能陷阱。數(shù)據(jù)庫(kù)執(zhí)行OFFSET 1000000 LIMIT 20時(shí)，必須先掃描并丟棄前100萬(wàn)行，成本隨頁(yè)數(shù)線性增長(zhǎng)。作者提到，某些場(chǎng)景下"深分頁(yè)"的查詢時(shí)間能從毫秒拖到秒級(jí)。

游標(biāo)分頁(yè)：像握著一根繩子，而不是數(shù)臺(tái)階

游標(biāo)分頁(yè)放棄了"第幾頁(yè)"的概念，改用錨定點(diǎn)。客戶端不再說(shuō)"給我第3頁(yè)"，而是說(shuō)"給我ID大于xyz的接下來(lái)20條"。

這個(gè)xyz就是游標(biāo)——通常是排序字段的編碼值（比如時(shí)間戳+ID的組合）。服務(wù)器用WHERE條件直接定位，而不是跳過(guò)N行。

優(yōu)勢(shì)很明顯：沒(méi)有深分頁(yè)的性能懸崖，因?yàn)閿?shù)據(jù)庫(kù)可以用索引直接定位游標(biāo)位置。也沒(méi)有跳過(guò)項(xiàng)問(wèn)題——即使中間數(shù)據(jù)被刪，游標(biāo)指向的相對(duì)位置不變，下一頁(yè)從正確的錨定點(diǎn)繼續(xù)。

代價(jià)同樣真實(shí)。你無(wú)法直接跳轉(zhuǎn)到"第50頁(yè)"，因?yàn)椴恢赖?0頁(yè)的游標(biāo)是什么。作者提到，總頁(yè)數(shù)、進(jìn)度條、直接跳轉(zhuǎn)這些UI模式全部失效。無(wú)限滾動(dòng)很合適，傳統(tǒng)分頁(yè)表格很尷尬。

還有一個(gè)工程細(xì)節(jié)：游標(biāo)需要編碼。作者建議把多個(gè)排序字段（如created_at + id）拼成字符串后Base64，避免客戶端篡改，也隱藏內(nèi)部實(shí)現(xiàn)。

決策框架：不是選更好的，是選更合適的

作者最后給了一個(gè)對(duì)照表，但核心邏輯可以壓縮成兩句話：

數(shù)據(jù)靜態(tài)、需要跳轉(zhuǎn)、用戶想看進(jìn)度 → 偏移量。比如后臺(tái)管理系統(tǒng)的表格，管理員可能直接點(diǎn)最后一頁(yè)。

數(shù)據(jù)動(dòng)態(tài)、實(shí)時(shí)性高、深分頁(yè)常見(jiàn) → 游標(biāo)。比如社交信息流、消息列表、股票行情——這些場(chǎng)景下跳過(guò)項(xiàng)問(wèn)題是不可接受的。

作者提到一個(gè)真實(shí)案例：某團(tuán)隊(duì)在實(shí)現(xiàn)"未讀消息"功能時(shí)，用偏移量分頁(yè)+標(biāo)記已讀。用戶邊讀邊標(biāo)記，列表實(shí)時(shí)收縮，結(jié)果頻繁出現(xiàn)消息"閃爍"或丟失。切到游標(biāo)分頁(yè)后，問(wèn)題消失。

還有一個(gè)混合策略：前幾頁(yè)用偏移量（支持跳轉(zhuǎn)），超過(guò)一定深度后自動(dòng)切換游標(biāo)（保性能）。作者警告這種方案增加了復(fù)雜度，"除非有明確數(shù)據(jù)證明需要，否則別急著上"。

無(wú)限滾動(dòng)+虛擬列表的場(chǎng)景，作者最終選了游標(biāo)分頁(yè)。虛擬列表只渲染視口內(nèi)的DOM節(jié)點(diǎn)，游標(biāo)分頁(yè)只拉取需要的數(shù)據(jù)塊，兩者配合能把內(nèi)存和請(qǐng)求都?jí)旱阶畹汀?/p>

他最后留下一個(gè)未解決的細(xì)節(jié)：游標(biāo)分頁(yè)的"上一頁(yè)"實(shí)現(xiàn)比想象中麻煩，特別是支持雙向無(wú)限滾動(dòng)的場(chǎng)景。讀者里做過(guò)類似需求的人，你們的游標(biāo)是單向還是雙向設(shè)計(jì)的？