删除百度缓存：源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /c8ca16172f65.html
📄
删除百度缓存：源站正常而边缘节点异常时应保留哪些证据
先给有条件的结论：如果源站返回正常、但边缘节点上的内容仍是旧版本，优先保留可复现的请求与响应证据，而不是先提交删除百度缓存。因为你要证明的不是“源站没问题”，而是“百度侧看到的副本与源站不一致”。若你无法复现差异，或差异只出现在你自己的浏览器会话中，这个结论不成立，应转向排查本地缓存、代理或账号态差异。
为什么源站正常不等于可以提交删除
源站正常只能说明你的服务器在某个时刻返回了正确内容。百度侧看到的内容可能来自多个中间环节：CDN 边缘节点、运营商透明代理、百度自身的抓取与索引副本。删除百度缓存处理的是百度结果页里那条快照或摘要，它不保证清理 CDN 边缘节点，也不保证重新抓取。如果异常其实在 CDN 层，提交删除后快照可能短暂消失，随后又因为百度再次抓取到旧边缘副本而恢复，问题被掩盖而不是解决。
因此判断顺序应该是：先确认异常发生在哪一层，再决定是修源站、刷边缘节点，还是提交删除请求。跳过这一步，最常见的代价是反复提交、反复出现，且没有留下能说明问题的记录。
需要保留的四类证据
证据的目标是让另一个人或另一个时间点的你能重复同样的观察。建议保留以下四类，并注明采集时间与时区。
- 原始响应证据：用
curl -I或浏览器开发者工具保存完整响应头，重点记录Cache-Control、Age、X-Cache、Last-Modified、ETag。这些字段能区分“边缘缓存未过期”和“源站确实返回了旧内容”。 - 边缘节点定位证据：同一 URL 从不同网络、不同地区多次请求，记录返回内容是否一致，以及响应头里暴露的节点标识。若只有部分请求命中旧版本，说明是节点级不一致，而不是全局问题。
- 百度侧副本证据：保存百度结果页中摘要、快照入口可见的文字与截图，并记录抓取时间。注意截图要包含采集时间，否则后续无法判断副本是否更新。
- 变更记录：源站最近一次内容修改时间、发布方式（直接改文件还是走发布系统）、CDN 刷新记录。没有这组记录，就无法解释为什么边缘节点还持有旧版本。
这四类证据里，前两类决定“要不要修边缘节点”，后两类决定“要不要提交删除百度缓存”。缺了前两类就提交，等于把 CDN 问题当成索引问题处理。
一个反例：差异只出现在登录态或特定浏览器
假设你观察到百度快照是旧标题，但用无痕窗口访问源站看到的是新标题。如果换一台设备、换一个网络后源站也显示旧标题，那么异常在边缘节点；如果只有你的常用浏览器显示旧标题，而无痕窗口和其他设备都正常，那更可能是本地缓存或浏览器扩展造成的假象。此时保留的“证据”其实是你自己环境的产物，提交删除百度缓存不会改变任何东西，反而会浪费一次处理机会。
这个反例的判别动作很简单：用无痕窗口加另一台设备各请求一次，若两者结果不同，先解决采集环境问题，再谈删除。
两种做法的取舍条件
做法一：先刷新 CDN 边缘节点，观察一段时间后再决定是否提交删除。适用条件是响应头中出现较高的 Age、节点标识显示命中的是边缘缓存、且源站内容确实已更新。代价是需要等待节点自然过期或主动刷新，期间百度仍可能抓到旧副本。
做法二：直接提交删除百度缓存，同时并行处理边缘节点。适用条件是百度侧副本明显过期、且你已保存了能证明源站与边缘不一致的响应头证据。代价是删除只作用于百度侧展示，若边缘节点未修好，重新抓取后旧内容可能再次出现。
选择依据不是哪个更快，而是异常层是否已确认。层未确认时，先做定位动作；层已确认在边缘时，修边缘优先；层已确认在百度副本且源站与边缘都已一致时，再提交删除。
下一步动作与结果如何影响后续
先做一次跨网络、跨设备的对照请求，把响应头和正文摘要保存下来。如果对照结果显示边缘节点返回旧版本，下一步是刷新或等待该节点过期，并记录刷新时间；刷新后再次对照，若所有节点一致，再检查百度侧副本是否仍为旧版本。若百度侧仍旧，此时提交删除百度缓存才有明确依据。
反过来，如果对照请求显示所有节点都已返回新版本，而百度摘要仍是旧的，那么问题在百度侧副本，保留好抓取时间与当前源站响应头即可提交。若对照请求本身无法复现差异，先排除本地缓存与代理，不要进入删除流程。这套动作的价值在于：每一步的结果都决定下一步该修哪里，而不是把所有异常都当成同一个问题处理。
