网站如何被百度收录：多层缓存返回不同版本时怎样定位一致性问题
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /068b759f5d27.html
📄
网站如何被百度收录：多层缓存返回不同版本时怎样定位一致性问题
先给有条件的结论：如果同一 URL 在不同网络、不同 UA 或不同入口下拿到不同 HTML，优先怀疑 CDN 边缘节点与源站之间的缓存键设计不一致，而不是百度抓取本身异常。只有当差异同时出现在回源请求和源站直连上，才应把排查重心移到应用层或数据库缓存。这个判断的前提是你能拿到至少两个版本的完整响应头，并且知道每个版本来自哪一层。
先分清“谁缓存了哪一份”
多层缓存通常至少包括浏览器缓存、CDN 边缘缓存、反向代理缓存、应用层对象缓存。它们各自按不同的键存储内容，常见键包括完整 URL、URL 加查询串、URL 加 Vary 头声明的字段、以及带 Cookie 的变体。一致性问题的根源往往不是某一层缓存坏了，而是两层用了不同的键，结果把本应相同的请求分到了不同副本。
一个可操作的区分方法是：对同一路径分别发起三种请求并记录响应头中的缓存命中标识、Age、Vary 和 ETag。第一种是普通请求，第二种带一个无关查询参数，第三种带与登录态相关的 Cookie。如果只有带 Cookie 的请求返回旧版本，说明变体缓存把匿名版本和登录版本混在了一起；如果带无关查询参数就返回旧版本，说明缓存键把查询串当成了内容区分依据，而你的页面并不依赖它。
两种做法该选哪一种
面对版本不一致，常见取舍是“先清缓存”与“先改缓存键”。两者都成立，但条件不同。
- 先清缓存适合差异只出现在少数边缘节点、且你能确认源站当前版本正确的情况。代价是清理通常只能覆盖你已知的节点，未清理的节点仍会返回旧版本，问题会以更低频率复现。动作是清理后立即用同一组请求复测，如果旧版本消失但过一段时间又出现，说明回源或应用层仍在产出旧内容，下一步应转向回源链路。
- 先改缓存键适合差异与请求特征稳定相关的情况，例如带某类 Cookie 或某个查询参数必现旧版本。代价是改动会影响缓存命中率，可能增加回源压力。动作是先把 Vary 或键规则改到测试环境，用同样的三种请求验证变体是否被正确区分，再决定是否上线。
如果两种做法都试过仍不一致，不要继续在缓存层加规则。此时应直接回源：绕过 CDN 和反向代理请求源站，比较源站返回是否也分版本。源站一致而边缘不一致，问题在缓存；源站本身就不一致，问题在应用逻辑或数据读取顺序。
一个会让上述结论失效的反例
假设你观察到旧版本只在夜间出现，白天一切正常。按上面的结论，你可能会去查夜间是否有缓存预热或批量清理任务。但还有一个合理解释：夜间有定时任务重建页面，而重建过程中先写入了不完整版本，缓存只是如实保存了它。这种情况下清缓存或改键都只能暂时掩盖，下一次任务运行仍会复现。
区分方法是看时间相关性是否稳定，以及旧版本内容是否具有“半成品”特征，例如缺少某段模块、字段为空、模板变量未替换。如果旧版本是完整的旧内容，偏向缓存层；如果是残缺内容，偏向写入顺序。请求量或抓取量归零不能单独证明处理正确，它也可能只是抓取节奏变化或入口调整的结果。
下一步动作与验证方式
确定层级后，下一步不是立刻全量修复，而是构造一个可重复的最小验证：固定一个 URL，固定一组请求头，在改动前后各记录一次响应头与正文摘要。改动只针对一个变量，例如只调整 Vary，或只清理一个节点。验证通过的标准是该 URL 在所有测试请求下返回同一版本，并且源站直连结果与边缘结果一致。
如果验证通过，再扩大到同类页面模板，而不是全站。扩大过程中若再次出现分版本，说明还有未识别的缓存键维度，应回到请求特征对比，而不是继续加清理频率。整个排查过程中，站点地图提交或 robots.txt 调整都不解决版本一致性问题，它们影响的是抓取与发现，不是同一 URL 返回哪一份内容。
