更新后仍显示旧内容排障
区分浏览器、代理/CDN、协商缓存与部署内容，先确认版本再讨论定向刷新。
适用范围与前提
HTTP 内容更新后的版本差异；不自动清缓存，不仅凭单个响应头判断新旧。
- 记录预期版本/文件哈希、发布时间、URL 和故障节点；不先做全站缓存清除。
- 仅访问获授权且已确认无写入副作用的资源；HEAD/GET 会产生请求和日志，重验证也可能增加源站负载。
- 示例 index.html 与 192.0.2.10 是占位目标，源站对照必须获得授权并保留正常 TLS/主机名校验；不公开源站或令牌。
命令仅供手动复制到获授权的环境执行。站点不会连接服务器；涉及网络的诊断可能产生请求或登录审计记录。
1. 确认旧内容来自哪一层
curl --head --max-time 5 https://example.com/index.html预期现象：记录状态、Cache-Control、Age、Expires、ETag、Vary 和 CDN 诊断头，与浏览器 Network 的 from memory/disk cache、Service Worker 及版本标记对照。Age 不是文件修改时间，ETag 不一定是哈希。
- 只有浏览器旧或 Service Worker 命中 → 临时对照浏览器缓存行为
- 命令和浏览器都旧或缓存层不明 → 请求重验证而不是要求删除缓存
- HEAD 不支持或无版本证据 → 升级求助前收集
2. 临时对照浏览器缓存行为
# 在开发者工具 Network 临时勾选 Disable cache 并刷新已授权页面，记录实际版本；检查 Application 中的 Service Worker 控制状态，不直接注销或删除站点数据。预期现象：此开关仅用于诊断且可能增加网络请求，不保证绕过 Service Worker 或 CDN。普通刷新、强制刷新和禁用缓存结果不同不代表根因已修复。
- 浏览器缓存或 Service Worker 版本策略已定位 → 修复建议（需人工确认）
- 绕过浏览器缓存仍旧 → 请求重验证而不是要求删除缓存
- 无法确认客户端版本与缓存来源 → 升级求助前收集
3. 请求重验证而不是要求删除缓存
curl --head --max-time 5 'https://example.com/index.html' -H 'Cache-Control: no-cache'预期现象：no-cache 通常要求复用前验证，不等于禁止存储或强制绕过所有 CDN；no-store 也不会自动清理旧缓存。304 无正文，需核对实际条件请求与本地缓存实体，不能据此认定部署已更新。
- 重验证后更新，缓存策略差异明确 → 修复建议（需人工确认）
- 仍旧或不同边缘节点不一致 → 在获授权条件下对照源站
- 已为预期版本 → 验证恢复
4. 在获授权条件下对照源站
curl --head --max-time 5 --resolve 'example.com:443:192.0.2.10' 'https://example.com/index.html'预期现象：替换文档地址为已批准源站；--resolve 保留 URL 的 Host/SNI 和 TLS 校验，可能直达源站并产生负载。源站要求专用认证或无法直连时停止，不绕过保护。由负责人同步核对部署文件哈希、版本和多节点一致性。
- 源站新、边缘旧 → 修复建议（需人工确认）
- 源站也旧或多节点部署不一致 → 修复建议（需人工确认）
- 源站不可访问或证据不足 → 升级求助前收集
修复建议（需人工确认）
- 先确认部署成功、路由映射和全部源站节点版本；备份配置，由负责人按发布/回退流程修正，不用清 CDN 掩盖部署失败。
- HTML 与带内容哈希资源采用适合的缓存策略，检查 max-age、s-maxage、验证器和 Vary；immutable 资源更新应使用新 URL。
- 定位具体缓存层与键后，经人工确认影响再定向刷新并观察源站负载；Service Worker 更新按应用策略发布，不全站删除用户存储。
验证恢复
- 在原浏览器与受影响边缘节点确认实际内容版本/哈希，不能仅看状态 200 或 Age 降低。
- 验证未变资源仍可合理缓存、条件请求正确，观察跨原缓存周期的新旧一致性与源站负载。
升级求助前收集
- 预期/实际版本、发布时间、脱敏 URL 和缓存头、命中节点、条件请求、Service Worker 状态与部署记录；不要公开源站敏感信息。