360收录多层缓存返回不同版本时怎样定位一致性问题
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /0d8690fc93d1.html
📄
360收录多层缓存返回不同版本时怎样定位一致性问题
先给结论：不要从最外层缓存开始逐层清，而是先固定一个可复现的请求标识，再在每一层缓存上比对同一标识对应的响应头与正文指纹。多数“不同版本”不是缓存坏了，而是各层用了不同的缓存键，或某一层忽略了 Vary、Cookie、Accept-Encoding 这类区分维度。缺少完整日志和权限时，你仍能用一个页面、一份响应头记录和一个指纹值，判断分歧出在哪一层，并决定下一步是改缓存键还是改回源策略。
先固定一个可复现的请求，再谈版本差异
你需要先选定一个具体对象：一个 URL，最好是你手上有权限访问、且确认已被 360 搜索抓取过的页面。用同一台机器、同一个出口 IP、同一份请求头连续请求多次，把每次的响应状态、响应头中的缓存相关字段、以及正文的指纹记录下来。指纹可以用正文的哈希，也可以用一个只在特定版本出现的短字符串，例如页面里某个区块的标题或一段注释。
关键动作是记录请求头里所有可能影响缓存的字段：Cookie、Accept-Encoding、Accept-Language、User-Agent，以及是否带查询串。如果这些字段在多次请求间发生变化，你看到的“不同版本”可能只是正常的内容协商结果，而不是缓存不一致。此时不能推出“缓存有 bug”，只能推出“缓存键包含了你没固定的维度”。
用响应头把分歧缩小到某一层
同一 URL 在不同层返回不同版本时，响应头是最省事的证据。重点关注这几类字段：标识缓存命中与否的字段、标识缓存新鲜期的字段、以及标识内容协商维度的 Vary。假设你连续请求三次，第一次正文是 A 版本，第二、三次是 B 版本，而响应头里第一次显示未命中、后两次显示命中，那么分歧很可能来自某一层在未命中时回源拿到了 A，而命中时返回了旧的 B，或者相反。
如果响应头里出现了 Age，且 Age 在多次请求间差异很大，说明中间至少有一层在独立计时。你可以据此做一个最小验证：把请求头里的 Cookie 去掉再请求一次，观察版本是否切换。若切换，说明某一层把 Cookie 纳入了缓存键，而另一层没有，这属于配置不一致，不是数据损坏。
缺少权限、看不到中间层日志时，你仍能得出结论的方向：响应头能证明分歧存在，但不能证明是哪一层的存储出了问题。这个区分很重要，因为前者对应改缓存键，后者对应清缓存或改回源。
把“版本不同”拆成三种可区分的成因
多层缓存返回不同版本，常见成因可以分成三类，它们的证据和下一步动作不同：
- 缓存键不一致：各层对 URL 的归一化不同，例如一层把查询串排序后当键，另一层原样保留。证据是同一 URL 加不同查询串时，命中与未命中的分布不一致。下一步是统一归一化规则。
- 内容协商维度被忽略：某层没有正确处理 Vary，对压缩、语言或设备类型返回了同一份缓存。证据是切换 Accept-Encoding 后正文指纹不变，但内容明显应为另一版本。下一步是补上 Vary 或按维度拆分缓存键。
- 回源与缓存时序错位：某层在回源拿到新版本后，另一层仍持有旧版本并继续命中。证据是响应头里 Age 与新鲜期字段互相矛盾。下一步是缩短该层新鲜期或改为主动失效。
这三类成因对应的处理动作不同，所以不要把“清一次缓存”当成通用解。清缓存只能验证时序错位，无法修复缓存键不一致。
一个注明假设的短例子
假设某页面有两个版本：旧版标题为“产品概览”，新版为“产品能力”。你在同一出口 IP 下连续请求五次，前两次返回旧版且响应头显示命中，后三次返回新版且显示未命中。去掉 Cookie 后再请求两次，都返回新版且显示未命中。
这个结果能推出的结论是：某一层把 Cookie 纳入了缓存键，带 Cookie 时命中了旧版本，不带 Cookie 时回源拿到新版本。不能推出的结论是：360 搜索抓取到的就是旧版本。因为抓取行为可能来自不同出口、不同请求头，你手上的这组请求不能代表搜索引擎的抓取路径。
下一步动作是：先确认该层是否应该按 Cookie 区分缓存。如果页面内容不因登录状态变化，就不该把 Cookie 纳入缓存键；如果会变化，则应补上 Vary。这个决定会影响你是否需要同时调整其他层的配置，否则改完一层，另一层仍会返回旧版本。
缺少完整数据和权限时的最小动作
如果你拿不到中间层日志，也没有权限改配置，仍可执行一个最小动作：对同一 URL 构造一组受控请求，只改变一个变量，其余保持不变，记录每次的响应头与正文指纹。变量优先级建议为 Cookie、Accept-Encoding、查询串。每改变一个变量，观察版本是否切换。
这个动作的结果只能说明“某个变量影响了返回版本”，不能说明“360 搜索看到的是哪个版本”。要判断搜索侧的情况，需要另找证据，例如抓取日志或页面在搜索结果中的展示，而这些证据往往不完整。因此，把缓存一致性问题与收录问题分开处理：前者解决同一 URL 返回不同内容，后者再单独核查抓取与索引状态。
最后提醒一点：robots.txt 的抓取限制不等于可靠的索引移除，站点地图不保证收录，这些手段都不能用来验证缓存版本是否一致。缓存一致性只能靠受控请求和响应头比对来定位，定位清楚后再决定是改缓存键、补 Vary，还是调整回源与失效策略。
