Boloop 阅读示意图（AI 生成）：搜索需要覆盖所有合格内容，而不只是当前页。

一个目录只有少量内容时，很容易表现得什么都正常。搜索能返回结果，筛选能减少卡片，列表也没有明显的空白。直到某条旧内容被点名寻找，才发现它明明还在系统里，目录却找不到。

Boloop 在早期后端回归中处理过目录截断问题。修复的重点并不是再加一个“加载更多”按钮，而是确认查询覆盖的是完整的合格内容集合，而不只是前端已经拿到的一小段记录。

这类问题适合在内容还少时提前验证。否则，页面看起来一直正常，遗漏的内容却可能一直没有机会被发现。

先区分没取到和被筛掉

目录找不到内容，可能有多种原因。资源可能没有发布，也可能不公开；查询可能搜了错误字段；请求可能只取了前一页；排序与分页边界也可能让记录遗漏或重复。

这些原因的处理方式不同。先把“后台存在”当成线索，再核对它是否有公开发布快照、是否符合当前类型和筛选条件，最后检查实际请求返回了什么。

Boloop 的早期修复明确要用经过校验的服务端查询和分页替换被截断的公开目录。这样，搜索、筛选和排序针对的是服务端能够公开的内容，而不是浏览器当前持有的卡片数组。

在这个顺序下，分页只是把一个已确定的查询结果分段返回。它不能先缩小数据，再假装已经搜索了全部内容。

查询参数也是界面的一部分

一个可恢复的目录，需要让查询文字、类型、排序和分页位置有明确状态。用户翻页再后退，应该回到刚才的结果；换一个语言，查询也不该无缘无故丢失。

服务端则需要校验参数。分页大小和偏移应在允许范围内，筛选值应属于实际支持的集合。无效值应被明确拒绝，而不是悄悄使用某个任意默认值，让前端以为请求已经按要求执行。

还有一个容易被忽略的细节：列表结果和筛选项数量必须遵循相容的公开范围。否则正文虽然没有泄露，筛选统计却可能透露隐藏内容的存在。我们在隔离回归中也检查了隐藏内容与 facets 的隔离情况。

测试数据必须跨过真正的边界

那轮独立验证准备了 205 条公开测试记录，并按 100、100、5 三段检查分页，核对没有重复和遗漏。205 是隔离环境中的测试数据数量，不是当时网站已有的真实内容规模。

选择这组数据的意义很直接：它超过单页上限，也超过两页，最后一页还有不足整页的尾段。只准备二十条记录，很可能把“前一百条之外无法找到”这样的缺陷整个绕过去。

除了统计总量，还需要对照记录的实际身份。三页加起来数量正确，仍可能是某条记录重复、另一条记录缺失。结果集合与预期 ID 集合相同，才回答了完整性问题。

同一轮还检查了缺少特定语言字段时的查询匹配、非法筛选，以及隐藏内容是否进入公开结果。它们都围绕同一个问题：这个目录究竟在查询什么。

浏览器还要走完跨页使用的过程

接口返回正确，不代表目录已经好用。真实浏览器验收使用过另一组 37 条隔离记录：第一页 24 条，第二页 13 条；后退返回第一页，前进重新进入第二页。

随后搜索一条不依赖当前页位置的指定内容，只返回目标记录；切换英文时保留查询，并显示相应语言内容。排序和内容类型筛选也分别进行了检查。

这组较小数据用于验证交互路径，205 条数据用于验证跨页集合完整性。两组检查各有用途，没有必要为了统一测试数字而把它们混在一起。

我们还在目录加载之后注入数据库故障，再发起搜索。页面显示错误和重试入口，URL 与输入保持不变；恢复数据源后，在原页重试得到了目标记录。一个失败请求不该顺手抹掉用户已经表达的查找意图。

给自己的目录做一次有针对性的复查

如果你正在做工具站、文章库或作品集，可以挑一条最近内容和一条最旧内容，先确认它们都符合公开规则，再分别从首页、目录和搜索进入。接着构造跨过分页上限的数据，在隔离环境中对照完整结果集合。

最后再走一次浏览器路径：翻页、搜索、清空条件、切换语言、后退、前进，以及请求失败后的重试。观察状态是否仍然连贯，而不只是每一步有没有返回卡片。

这次 Boloop 的修复与验收发生在早期云端隔离环境中，没有使用线上数据库来凑测试记录，也没有测出生产吞吐量或 Worker 内存极限。它支持的结论很具体：被检查的目录查询、分页完整性和浏览器恢复路径通过了验证。

把这个结论说具体，日后内容增长时就知道应该重测哪一段。目录的可靠性，也就不必等到有人找不到东西之后才开始讨论。