网站缓存 - 重复或冲突信号该清理还是该版本化
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /0a07db2742e1.html
📄
网站缓存 - 重复或冲突信号该清理还是该版本化
处理网站缓存带来的重复或冲突信号，核心判断是：先确认“同一份内容是否被多个缓存标识同时暴露”。如果是，优先清理旧缓存标识并统一入口；如果旧标识已被外部引用、无法立即下线，则用版本化标识隔离新旧内容，再逐步迁移。清理适合可控范围，版本化适合迁移期过渡，二者不能混用。
准备：先分清三类缓存信号
动手前先做一次信号盘点，否则容易把“缓存问题”误当成“内容重复问题”。
- URL 级重复：同一内容能通过带参数、带大小写差异或带结尾斜杠的多个地址打开，缓存各存一份。
- 响应头冲突：同一地址先后返回不同的
Cache-Control、ETag或Last-Modified，中间缓存不知道该信哪份。 - 版本冲突：静态资源文件名不变但内容已更新，旧缓存与新文件同时被引用。
检查方法：用浏览器开发者工具的 Network 面板记录同一地址两次请求的响应头，对比 ETag 与 Cache-Control 是否一致；再用命令行工具请求同一地址，确认 CDN 与源站返回是否相同。这一步只做记录，不改配置。判断结果：若同一地址响应头稳定，问题在 URL 扩散；若响应头来回变化，问题在缓存层配置。
实施：清理与版本化的选择条件
这是本题最关键的一步，选错方向会让后续验证失去意义。
选清理，当满足以下条件：旧地址没有外部反向链接、没有投放中的广告落地页、没有已提交的站点地图条目；你能在源站和 CDN 两侧同时刷新缓存。做法是统一 301 到规范地址，删除旧缓存键，并在响应头中给规范地址设置较长的 Cache-Control。
选版本化，当旧地址已被引用、短期内无法全部替换。做法是保留旧地址可访问，但让新内容使用带版本标识的资源名，例如把样式文件从 style.css 改为 style.v2.css，并在页面中只引用新文件名。旧文件继续返回旧内容，避免新旧混用。
注意：robots.txt 的抓取限制不等于可靠的索引移除，它只能阻止抓取，不能保证已缓存或已索引的副本消失。站点地图也不保证收录，提交后仍需逐一核对实际返回。
验证：用可复现的检查项确认结果
改完后按顺序验证，不要只看一个页面。
- 对规范地址连续请求三次，确认
ETag与Cache-Control三次一致。 - 对旧地址请求一次，确认返回 301 或明确的旧版本内容，而不是与规范地址相同的新内容。
- 抽查站点地图中的地址，确认每个地址返回的状态码与预期一致。
- 若使用 HTTPS，确认证书链完整；HTTPS 不保证安全无漏洞或排名，它只是传输层条件之一。
判断结果：三次响应头一致且旧地址行为明确，说明冲突已收敛；若仍出现两种响应头交替，说明还有一层缓存未刷新，需要回到准备阶段重新定位。
维护：把缓存标识纳入发布流程
冲突往往在下次发布时重现。维护阶段要固定两件事：一是静态资源命名规则，内容变更必须换文件名或换版本参数；二是发布后自动请求规范地址并记录响应头，与上一次发布对比。不同搜索引擎对缓存与索引的处理方式不同，需要分别核查各自的实际返回，不能用一个平台的结果推断另一个平台。
下一步：挑一个当前存在重复信号的地址，按上面的准备清单记录它的响应头与可访问地址，再决定走清理还是版本化。
