Boloop 閱讀示意圖（AI 生成）：搜索需要覆蓋所有合格內容，而不只是當前頁。

一個目錄只有少量內容時，很容易表現得什麼都正常。搜索能返回結果，篩選能減少卡片，列表也沒有明顯的空白。直到某條舊內容被點名尋找，才發現它明明還在系統裡，目錄卻找不到。

Boloop 在早期後端回歸中處理過目錄截斷問題。修復的重點並不是再加一個「載入更多」按鈕，而是確認查询覆蓋的是完整的合格內容集合，而不只是前端已經拿到的一小段記錄。

這類問題適合在內容還少時提前驗證。否则，頁面看起來一直正常，遺漏的東西卻可能一直沒有機會被發現。

先區分沒取到和被篩掉

目錄找不到內容，可能有多種原因。資源可能沒有發布，也可能不公開；查询可能搜了錯誤欄位；请求可能只取了前一頁；排序與分頁邊界也可能讓記錄遺漏或重複。

這些原因的處理方式不同。先把「後台存在」當成線索，再核對它是否有公開發布快照、是否符合當前類型和篩選條件，最後檢查實際请求返回了什麼。

Boloop 的早期修復明確要用經過校驗的服務端查询和分頁替換被截斷的公開目錄。這樣搜索、篩選和排序針對的是服務端能夠公開的內容，而不是瀏覽器當前手裡的卡片數組。

在這個順序下，分頁只是把一個已確定的查询結果分段返回。它不能先縮小數據，再假裝已經搜索了全部內容。

查询參數也是界面的一部分

一個可恢復的目錄，需要讓查询文字、類型、排序和分頁位置有明確狀態。用戶翻頁再後退，應該回到剛才的結果；換一個語言，查询也不該无缘無故遺失。

服務端則需要校驗參數。分頁大小和偏移應在允許範圍內，篩選值應屬於實際支援的集合。無效值應被明確拒絕，而不是悄悄使用某個任意默認值，讓前端以為请求已經按要求執行。

還有個容易被忽略的細節：列表結果和篩選項數量必須遵循相容的公開範圍。否则正文雖然沒有洩露，篩選統計卻可能透露隱藏內容的存在。我們在隔離回歸中把隱藏內容與 facets 的隔離也納入了檢查。

測試數據必須跨過真正的邊界

那輪獨立驗證準備了 205 條公開測試記錄，並按 100、100、5 三段檢查分頁，核對沒有重複和遺漏。205 是隔離環境中的測試數據數量，不是當時網站已有的真實內容規模。

選擇這組數據的意義很直接：它超過單頁上限，也超過兩頁，最後一页還有不足整頁的尾段。只準備二十條記錄，很可能把「前一百條之外無法找到」这样的缺陷整個繞過去。

除了數總量，還需要對照記錄的實際身份。三頁加起来數量正確，仍可能是某條記錄重複、另一條記錄缺失。結果集合與預期 ID 集合相同，才回答了完整性問題。

同一輪還檢查了缺少特定語言欄位時的查询匹配、非法篩選，以及隱藏內容是否進入公開結果。它們都圍繞同一個問題：這個目錄究竟在查询什麼。

瀏覽器还要走完跨頁使用的過程

接口返回正確，不代表目錄已經好用。真實 browser 驗收使用過另一組 37 條隔離記錄：第一頁 24 條，第二頁 13 條；後退返回第一頁，前進重新進入第二頁。

隨後搜索一條不依賴當前頁位置的指定內容，只返回目標記錄；切換英文時保留查询，並顯示相應語言內容。排序和內容類型篩選也分別檢查。

這組較小數據用於驗證交互路徑，205 條數據用於驗證跨頁集合完整性。兩組檢查各有用途，沒有必要為了統一個測試數字把它們混在一起。

我們還在目錄載入之後注入數據庫故障，再發起搜索。頁面顯示錯誤與重試入口，URL 和輸入保持不变；恢復數據源後，在原頁重試得到目標記錄。一個失敗请求該順手抹掉用戶已經表達的查找意圖。

給自己的目錄做一次有針對性的複查

如果你正在做工具站、文章庫或作品集，可以挑一條最近內容和一條最舊內容，先確認它們都符合公開規則，再分別從首頁、目錄和搜索進入。接著構造跨過分頁上限的數據，在隔離環境對照完整結果集合。

最後再走一次 browser 路徑：翻頁、搜索、清空條件、切語言、後退、前進，以及请求失敗後的重試。觀察狀態是否仍然連貫，而不只是每一步有没有返回卡片。

本次 Boloop 的修復與驗收發生在早期雲端隔離環境，沒有使用線上數據庫來湊測試記錄，也沒有測出生產吞吐量或 Worker 記憶體極限。它支援的結論很具體：被檢查的目錄查询、分頁完整性和 browser 恢復路徑通過了驗證。

把這個結論說具體，日後內容增長時就知道應該重測哪一段。目錄的可靠性，也就不必等到有人找不到東西之後才開始討論。