索引量查询，多层缓存返回不同版本时怎样定位一致性问题

📍 WDQWDWQD987AAAAA:136.243.57.164
📱 Mozilla/5.0 (compatible; QlyzeBot/1.0; +https://app.qlyze.io/bot)
🔗 /f2b5021a9e2c.html
📄

先给结论：不要从“哪个数字是真的”入手，而要先确定各层缓存各自绑定的是哪个上游版本，再用同一批URL逐层比对。假设某站点在CDN、反向代理和页面缓存三层都缓存了HTML，同一批URL在索引量查询里出现少量样本正常、放大到全站后大量对不上的情况，问题通常不是索引量本身算错，而是各层返回的版本不同。

先固定一个可复现的样本集

从索引量查询结果里挑三类URL：一类是查询显示已收录且近期有变化的，一类是显示已收录但内容长期不变的，一类是显示未收录但站内确认可访问的。每类各取若干条，记录完整URL、查询时间、查询时看到的标题或摘要片段。这个样本集的作用不是证明全站状态，而是给后续逐层比对提供同一把尺子。

如果只拿“已收录”的URL去测缓存，很容易漏掉真正的问题层，因为已收录页面往往已经被上游更新覆盖。把未收录样本一起纳入，才能看出缓存返回的旧版本是否恰好对应索引量查询里那个过时的摘要。

对样本集里的每个URL，依次从浏览器直连源站、绕过CDN回源、经过CDN、经过反向代理取回响应。每次记录三样东西：响应里的内容指纹（例如正文中一段稳定文字的哈希）、响应头里的缓存相关字段、以及该层返回的标题。不要只看状态码，200不代表版本一致。

实际操作时，可以先用curl -s URL | sha256sum这类命令取内容指纹，再对比各层结果。若源站指纹与CDN指纹不同，说明CDN缓存了旧版本；若CDN与反向代理不同，说明中间层没有正确失效。把每层的差异写成一张对照表，而不是凭印象判断。

这一步的结果直接决定下一步：如果只有CDN层偏离，优先查CDN的缓存键和刷新记录；如果源站本身在不同时间返回不同内容，那问题在源站而不是缓存层。

索引量查询反映的是查询时刻索引里的状态，它本身也可能滞后于源站最新版本。因此看到查询结果与源站不一致时，有两种成立条件：

如果逐层取回显示源站、CDN、反向代理返回的是同一新版本，只有索引量查询还是旧摘要，那更可能是索引更新滞后，应继续观察同一批URL在后续查询中的变化，而不是立刻改缓存配置。
如果逐层取回显示CDN或反向代理返回旧版本，而源站已是新版本，那缓存不一致成立，应优先处理缓存失效路径，再复查索引量查询是否随之变化。

这两种情况的处理顺序不能颠倒。先改缓存再查索引，会把两个变量混在一起，无法判断到底是哪一步起了作用。

假设某站点对文章页设置了较长的CDN缓存时间，同时反向代理也缓存HTML。运维在发布新标题后只刷新了CDN，没有刷新反向代理。此时索引量查询里部分URL仍显示旧标题。逐层比对会发现：源站是新标题，反向代理是旧标题，CDN因为回源到反向代理也拿到旧标题。问题定位在反向代理层，而不是CDN或索引。

按这个结论，先刷新反向代理缓存，再刷新CDN，然后重新取回同一批URL确认各层指纹一致。如果一致后索引量查询仍未更新，那属于索引侧滞后，继续观察；如果刷新后仍不一致，说明缓存键里可能包含了会变化的参数，需要检查缓存键配置。这个顺序保证每次只改变一个变量。

个别样本一致不代表全站一致。当样本量放大后例外增多，常见原因是不同URL命中了不同的缓存规则，例如带查询参数的URL、移动端UA、登录态页面走了不同的缓存键。此时不能把少量样本的结论直接套到全站，应按缓存规则分组，每组单独抽样比对。

另外要注意，robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录。即使缓存层全部一致，索引量查询的结果仍可能因为抓取和索引策略而不同。定位一致性问题的目标是让各层返回同一版本，而不是承诺索引量查询会立刻反映这个版本。