📍 WDQWDWQD987AAAAA:216.73.216.157
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /0383fdef2f87.html
📄

网站缓存改版或迁移时应核对什么：交付前必须确认的四类信息

网站缓存改版或迁移时，应核对的是缓存层级、失效规则、版本标识和回滚路径，而不是只确认页面能打开。多人协作中最容易返工的地方，是前端改了资源、运维改了CDN、SEO改了URL，但没有人对“旧缓存什么时候失效、失败后怎么退回”负责。下面从交付结果倒推，给出可以直接使用的核对清单。

先列出所有缓存层，再谈清理

“网站缓存”在实际系统里通常不止一层。至少包括：浏览器缓存、CDN或反向代理缓存、应用层对象缓存、数据库查询缓存，以及部分建站系统自带的页面缓存。改版或迁移时，如果只清一层，用户仍可能看到旧页面。

交付前应形成一张表，每一行是一个缓存层，列包括：

• 缓存位置：浏览器、CDN、服务器、应用、数据库。
• 缓存对象：HTML、CSS、JS、图片、接口响应、整页。
• 失效方式：改文件名、改版本参数、主动刷新、等待过期、重启服务。
• 责任人：谁有权执行，谁负责验证。
• 回滚方式：清错了或新版本异常时如何恢复。

判断依据很简单：任何一层如果写不出“谁在什么时间用什么方式让它失效”，就不算交付完成。适用条件是多人协作、有独立运维或CDN管理方的项目；个人小站可以简化，但至少要有浏览器缓存和服务器缓存的说明。

核对URL与版本标识是否一致

改版时常见做法是给静态资源加哈希或版本号，例如把 style.css 改成 style.a1b2c3.css。迁移时则要确认旧URL是否保留、是否跳转、跳转后缓存键是否变化。

需要核对的具体项：

1. HTML中引用的资源路径是否全部指向新版本，没有残留旧路径。
2. CDN缓存键是否包含版本参数或文件名哈希。如果缓存键忽略查询参数，改 ?v=2 可能无效。
3. 迁移后旧域名和新域名的缓存是否分别处理，避免旧域名继续返回旧内容。
4. 服务端返回的缓存头是否与预期一致，例如 Cache-Control、ETag、Last-Modified。

假设一个场景：改版后首页HTML更新了，但CDN仍缓存旧HTML，用户拿到的旧HTML又引用旧CSS，于是出现样式错乱。这时清浏览器缓存没有用，必须让CDN上的HTML失效。这个例子说明，核对顺序应是先确认缓存对象，再决定清理动作。

把任务、责任和验收写成可检查的条目

多人协作减少返工的关键，不是多开会，而是把“完成”定义成别人可以复现的检查结果。可以按下面格式交付：

• 任务：刷新CDN上 / 和 /assets/* 的缓存。
• 责任：由运维执行，前端提供需要刷新的路径清单。
• 验收：用无痕窗口和带缓存窗口分别访问，确认返回内容版本一致；用命令行查看响应头中的缓存标识。
• 失败处理：如果刷新后仍返回旧内容，先确认请求是否命中预期节点，再检查缓存键和回源规则，不要直接反复刷新。

验收时至少区分两种现象：可能原因是本地浏览器缓存未过期；已经定位的原因是响应头显示CDN命中且返回旧版本。只有后者才能确定是CDN侧问题。把“可能”和“已定位”分开写，能避免团队互相指责。

迁移后还要核对索引与抓取相关文件

网站缓存问题有时会和抓取问题混在一起。需要单独核对：robots.txt 是否误屏蔽了新路径；站点地图是否指向新URL；旧URL是否返回301而不是302或404。这里要明确：robots.txt 的抓取限制不等于可靠的索引移除；站点地图不保证收录；HTTPS不保证安全无漏洞或排名。它们各自只解决各自的问题，不能替代缓存核对。

如果迁移涉及域名更换，还应确认新域名下资源可访问、证书有效、跳转链不超过一跳。适用条件是搜索引擎可见的站点；内部系统或纯登录后台可以只核对缓存和跳转，不必处理索引文件。

下一步：先做一次缓存清单评审

把上面四类信息整理成一页清单，在改版或迁移上线前让前端、后端、运维和SEO各确认自己负责的行。任何一行缺少责任人或验收方法，就先不进入发布环节。这样做的直接结果是：出问题时能快速判断是哪一层缓存、由谁处理、如何回滚，而不是靠反复清缓存碰运气。