百度新闻收录多层缓存返回不同版本时怎样定位一致性问题
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /9a0572e00002.html
📄
百度新闻收录多层缓存返回不同版本时怎样定位一致性问题
先给有条件的结论：如果同一篇新闻在不同节点返回的 HTML 主体、标题或发布时间不一致，而源站数据库只保留一个版本，那么问题通常出在“源站发布后又被修改”与“中间层缓存未同步失效”的组合上，而不是百度新闻收录本身出错。这个结论成立的前提是：你能确认源站只有一个权威版本，且各层缓存都有可查的键与过期时间。反例是源站本身存在多版本写入（例如编辑后台与发布接口分别落库），此时缓存只是把源站的分歧放大，定位方向要改为先统一写入。
先分清“版本不同”发生在哪一层
多层缓存一般包括：源站应用层缓存、反向代理或 CDN 边缘缓存、以及百度侧抓取后形成的快照或索引版本。定位的第一步不是猜，而是把每一层可观察到的输出固定下来。做法是准备同一 URL 的若干次请求，并记录请求时间、请求来源（直连源站、经过 CDN、模拟百度蜘蛛的 UA）、响应头中的缓存标识（如 Age、Cache-Control、ETag、Last-Modified）以及正文中的标题和发布时间。
实际动作：对同一 URL 在 10 分钟内分别直连源站和经过 CDN 各取 3 次响应，把标题、发布时间、正文首段、响应头缓存字段抄进同一张对照记录。结果如果显示直连源站三次一致、经过 CDN 三次也一致但两者不同，就能把分歧锁定在 CDN 与源站之间；如果同一路径三次都不同，说明缓存键或过期策略本身不稳定，下一步应先查键的组成，而不是继续扩大抽样。
用可区分原因的证据缩小范围
几种常见原因会留下不同的证据特征，可以据此区分：
- 源站发布后修改但未刷新缓存：直连源站返回新版本，CDN 返回旧版本，且旧版本的 Age 较大、Last-Modified 较早。此时缓存层只是没有及时感知变更。
- 缓存键遗漏了会变化的维度：同一 URL 带不同查询参数、不同 UA 或不同 Accept-Encoding 时返回不同正文，说明键没有覆盖这些维度，命中到了别的对象。
- 源站多版本写入：直连源站多次请求本身就返回不同标题或发布时间，缓存层只是如实转发。这时问题不在缓存，而在写入链路。
- 百度侧快照滞后：源站与 CDN 都已一致，但百度新闻收录展示的仍是旧版本。这通常是抓取与更新节奏问题，不能靠刷新 CDN 解决。
判断时要注意：请求量下降、抓取量归零这类现象不能单独证明某一层处理正确，它们也可能来自抓取配额调整、robots 规则变化或站点整体可用性波动。把“现象消失”直接当成“原因已修复”是常见的误判。
一个注明假设的短例子
假设某新闻站有源站、CDN 两层缓存，编辑在发布 2 小时后修改了标题，但只调用了源站刷新接口，没有通知 CDN。此时直连源站返回新标题，CDN 仍返回旧标题，百度侧抓到的可能是旧标题。按照上面的对照记录，你会看到：源站一致为新、CDN 一致为旧、两者 Last-Modified 相差约 2 小时。这个证据组合指向“变更未传播到边缘”，而不是源站写入错误。
反过来，如果编辑后台和发布接口各自写了一份数据，源站两次请求就返回不同标题，那么无论怎么刷新 CDN，边缘层都会在两次回源之间摇摆。这个例子里的数字只用于说明比较方法，不代表任何真实站点的表现。
确认方向后的下一步动作
如果证据指向缓存未同步，下一步是检查变更传播路径：源站修改后是否主动清除对应缓存键，清除是否覆盖了所有相关维度，过期时间是否长到让旧版本持续可见。如果证据指向源站多版本，下一步是收敛写入入口，让同一 URL 只有一个权威数据来源，再处理缓存。
需要提醒的是，robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录，这些手段不能替代对版本一致性的修复。只有当源站、缓存层、百度侧三方对同一 URL 返回的标题与发布时间趋于一致后，再去看百度新闻收录的变化才有比较意义；否则你观察到的只是不同层各自的旧副本。
