Boloop 製作的閱讀示意圖：先查詢完整的合格內容集合，再將結果分頁。
一個目錄只有少量內容時，很容易表現得什麼都正常。搜尋能回傳結果，篩選能減少卡片，列表也沒有明顯的空白。直到某條舊內容被點名尋找，才發現它明明還在系統裡，目錄卻找不到。
Boloop 在早期後端迴歸中處理過目錄截斷問題。修復的重點並不是再加一個「載入更多」按鈕，而是確認查詢涵蓋的是完整的合格內容集合，而不只是前端已經拿到的一小段記錄。
這類問題適合在內容還少時提前驗證。否則，頁面看起來一直正常，遺漏的東西卻可能一直沒有機會被發現。
先區分沒取到和被篩掉
目錄找不到內容，可能有多種原因。資源可能沒有發布，也可能不公開；查詢可能搜了錯誤欄位；請求可能只取了前一頁；排序與分頁邊界也可能讓記錄遺漏或重複。
這些原因的處理方式不同。先把「後台存在」當成線索，再核對它是否有公開發布快照、是否符合目前類型和篩選條件，最後檢查實際請求回傳了什麼。
Boloop 的早期修復明確要用經過驗證的伺服器查詢和分頁替換被截斷的公開目錄。這樣搜尋、篩選和排序針對的是伺服器能夠公開的內容，而不是瀏覽器目前手裡的卡片陣列。
在這個順序下，分頁只是把一個已確定的查詢結果分段回傳。它不能先縮小資料，再假裝已經搜尋了全部內容。
查詢參數也是介面的一部分
一個可恢復的目錄，需要讓查詢文字、類型、排序和分頁位置有明確狀態。使用者翻頁再回上一頁，應該回到剛才的結果；換一個語言，查詢也不該無緣無故丟失。
伺服器則需要驗證參數。分頁大小和位移應在允許範圍內，篩選值應屬於實際支援的集合。無效值應被明確拒絕，而不是悄悄使用某個任意預設值，讓前端以為請求已經按要求執行。
還有一個容易被忽略的細節：列表結果和篩選項目數量必須遵循相容的公開範圍。否則正文雖然沒有洩露，篩選統計卻可能透露隱藏內容的存在。我們在隔離迴歸中把隱藏內容與 facets 的隔離也納入了檢查。
測試資料必須跨過真正的邊界
那輪獨立驗證準備了 205 條公開測試記錄，並按 100、100、5 三段檢查分頁，核對沒有重複和遺漏。205 是隔離環境中的測試資料數量，不是當時網站已有的實際內容規模。
選擇這組資料的意義很直接：它超過單頁上限，也超過兩頁，最後一頁還有不足整頁的尾段。只準備二十條記錄，很可能把「前一百條之外無法找到」這樣的缺陷整個繞過去。
除了數總量，還需要對照記錄的實際身分。三頁加起來數量正確，仍可能是某條記錄重複、另一條記錄缺失。結果集合與預期 ID 集合相同，才回答了完整性問題。
同一輪還檢查了缺少特定語言欄位時的查詢比對、非法篩選，以及隱藏內容是否進入公開結果。它們都圍繞同一個問題：這個目錄究竟在查詢什麼。
瀏覽器還要走完跨頁使用的過程
介面回傳正確，不代表目錄已經好用。實際瀏覽器驗收使用過另一組 37 條隔離記錄：第一頁 24 條，第二頁 13 條；上一頁返回第一頁，下一頁重新進入第二頁。
隨後搜尋一條不依賴目前頁面位置的指定內容，只回傳目標記錄；切換英文時保留查詢，並顯示相應語言內容。排序和內容類型篩選也分別檢查。
這組較小資料用於驗證互動路徑，205 條資料用於驗證跨頁集合完整性。兩組檢查各有用途，沒有必要為了統一一個測試數字把它們混在一起。
我們還在目錄載入之後注入資料庫故障，再發起搜尋。頁面顯示錯誤與重試入口，URL 和輸入保持不變；恢復資料來源後，在原頁重試得到目標記錄。一個失敗請求不該順手抹掉使用者已經表達的查找意圖。
給自己的目錄做一次有針對性的複查
如果你正在做工具站、文章庫或作品集，可以挑一條最近內容和一條最舊內容，先確認它們都符合公開規則，再分別從首頁、目錄和搜尋進入。接著建立跨過分頁上限的資料，在隔離環境對照完整結果集合。
最後再走一次瀏覽器路徑：翻頁、搜尋、清空條件、切語言、上一頁、下一頁，以及請求失敗後的重試。觀察狀態是否仍然連貫，而不只是每一步有沒有回傳卡片。
這次 Boloop 的修復與驗收發生在早期雲端隔離環境，沒有使用線上資料庫來湊測試記錄，也沒有測出正式環境吞吐量或 Worker 記憶體極限。它支持的結論很具體：被檢查的目錄查詢、分頁完整性和瀏覽器恢復路徑通過了驗證。
把這個結論說具體，日後內容增加時就知道應該重測哪一段。目錄的可靠性，也就不必等到有人找不到東西之後才開始討論。