📍 WDQWDWQD987AAAAA:216.73.216.56
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /b6cba8231e71.html
📄

网站缓存：批量页面只有一部分被发现时怎样划分对照组

不要按“已发现”和“未发现”直接分两组就下结论。更稳的做法是先把批量页面按可观测特征分层，再在层内做小规模对照：例如同一模板、同一发布时间段、同一目录层级、同一缓存策略的页面各取若干，其中一半主动触发缓存刷新，另一半保持原状，观察后续发现情况是否分化。如果分化只出现在某一层，问题更可能出在该层的缓存键、TTL 或回源行为上；如果所有层都分化，则要优先怀疑站点地图、内链或抓取预算等全局因素。

先明确“被发现”在这一步指什么

“被发现”至少可以指三种不同状态：URL 被爬虫请求过、页面被成功抓取、页面进入索引候选。三者对应的缓存影响完全不同。缓存主要影响的是“爬虫请求时拿到的响应内容与状态”，而不是索引决策本身。因此对照组要记录的是：请求是否到达源站、响应头中的缓存标识、响应体是否包含目标链接或正文。

如果只记录“有没有被发现”，你无法判断是缓存把请求挡在了边缘节点，还是源站返回了不一致的内容。建议在对照实验里至少保留以下字段：

• 请求时间与来源（站内入口、站点地图、外部链接）
• 响应状态码与缓存命中标识（如 X-Cache、Age、CF-Cache-Status 等，具体字段取决于你的缓存层）
• 响应体是否与源站一致（可用同一 URL 加随机查询参数绕过缓存做一次比对）
• 该 URL 所属的模板、目录、发布时间段

只有把这些字段补齐，后面的分组才有意义。

划分对照组时，先分层再随机

直接随机抽样在页面量大时容易把不同模板、不同缓存规则的页面混在一起，导致组间差异被稀释。更合理的顺序是：

1. 按模板或目录把批量页面分成若干层，例如列表页、详情页、聚合页。
2. 在每一层内随机取两组，一组作为“刷新缓存”组，一组作为“保持原状”组。
3. 两组在发布时间、内链数量、是否在站点地图中尽量接近，避免把时间因素误判为缓存因素。
4. 只对刷新组执行一次明确的缓存清理动作，记录清理前后的响应头变化。

这样做的结果是：如果刷新组后续被发现的比例明显高于保持组，而其他层没有同样差异，你就可以把下一步动作收窄到该层的缓存配置上，而不是全站重刷。

一个会让结论失效的反例

假设你在一批详情页上做了刷新对照，发现刷新组被发现得更多，于是准备全站清缓存。但如果这批详情页恰好都集中在同一发布时间段，而该时间段又刚好赶上站点地图重新提交或内链结构调整，那么“刷新缓存”和“站点地图更新”就是同时发生的。此时你无法把差异单独归因给缓存。

更麻烦的是，如果未发现的那部分页面本来就不在站点地图里，或者内链指向的是带参数的版本，那么缓存刷新与否根本不是主因。这种情况下，对照组划分得再整齐，结论也会失效。判断方法很简单：检查未发现页面是否具备独立的站内入口和站点地图条目。如果没有，先补入口，再谈缓存。

下一步动作：先做可逆的小范围清理

在对照组出现分化后，不要立刻全站刷新。先选分化最明显的那一层，执行一次可逆的缓存清理，并记录清理后 24 到 48 小时内该层页面的请求到达情况。如果请求开始到达源站且响应体一致，说明缓存层确实是阻塞点，可以把清理范围扩大到同层其他页面；如果请求仍然不到达，或者到达后响应体依旧不一致，则问题更可能在入口或源站逻辑上，此时继续清缓存只会增加回源压力而不解决发现问题。

把这个判断写进下一步：只有当同一层内刷新组与保持组的差异可重复出现，且排除了站点地图和内链变化后，才值得把清理动作推广到相邻层。否则，先回到入口和内容一致性检查。