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

网站缓存，怎样与开发人员交接问题：一份按优先级的排查清单

与开发人员交接网站缓存问题，核心是把“用户看到旧页面”这类模糊描述，转成可复现的现象、明确的缓存层级和判断依据。时间和人手有限时，先确认问题出在浏览器、CDN 还是服务端，再按影响面排序处理，不要一上来就要求清空所有缓存。

先分清是哪一层缓存在起作用

网站缓存通常至少涉及四层：浏览器本地缓存、CDN 边缘缓存、反向代理或应用层缓存、数据库查询缓存。不同层的表现和排查手段不一样，交接时必须先定位层级，否则开发改了服务端，问题可能仍然存在。

• 要查什么：问题页面在哪些环境出现旧内容，是所有人还是个别用户。
• 怎么查：让反馈者提供浏览器开发者工具的 Network 面板截图，重点看响应头里的 Cache-Control、Age、ETag、Last-Modified，以及状态码是否为 200 (from disk cache) 或 304。
• 结果说明什么：如果显示 from cache 且 Age 较大，问题可能在浏览器或 CDN；如果每次都是 200 且内容仍旧，问题更可能在服务端或数据源。

交接时先固定最小复现信息

开发人员最需要的是能稳定复现的输入。缺少这些信息，排查会变成反复猜测。

1. 要查什么：具体 URL、发生时间、用户地区、登录状态、设备与浏览器版本。
2. 怎么查：用无痕窗口和已登录窗口各访问一次，再用 curl -I 查看响应头，对比差异。
3. 结果说明什么：如果无痕窗口正常、登录窗口异常，可能是按用户或 Cookie 区分的缓存；如果两者都异常，范围更大。

把这些信息写进一条工单，比口头说“页面没更新”有效得多。若涉及具体 CDN 或托管平台，应让开发人员确认该平台当前的缓存规则和刷新方式，而不是沿用旧文档里的操作位置。

按影响面决定先处理哪一项

时间和人手有限时，优先级应由影响面和可逆性决定，而不是由修复难度决定。

• 要查什么：受影响的是首页、核心转化页，还是低频内容页。
• 怎么查：抽样统计问题 URL 的访问量级，确认是否影响支付、登录、表单提交等关键流程。
• 结果说明什么：影响关键流程且范围明确的，先做定向刷新或回滚；只影响少量静态页的，可以排入常规修复。

定向刷新比全站清缓存更安全，因为它不会同时打满源站。但要注意，刷新 CDN 不等于删除搜索引擎索引，robots.txt 的抓取限制也不等于可靠的索引移除，站点地图同样不保证收录。缓存交接应聚焦在内容分发层，不要把索引问题混进来。

交接清单：每项都写清判断结果

下面这份清单可以直接复制到工单里，逐项填写。

• 响应头检查：查看 Cache-Control 的 max-age、s-maxage、no-store 设置。若 s-maxage 很长，CDN 会持续返回旧内容。
• 缓存键检查：确认缓存是否按 URL、查询参数、Cookie、语言或设备区分。缓存键过粗会导致不同用户看到同一份内容。
• 刷新与失效机制：确认发布新内容时是主动刷新、等待过期，还是依赖版本号。主动刷新需要开发提供可执行命令或后台操作路径。
• 回滚条件：写明什么情况下回滚缓存配置，以及回滚后如何验证。
• 验证方式：刷新后用同一 URL 重新请求，确认响应头中的 Age 归零或内容已更新，并让反馈者复测。

技术示例中，如果要在工单里写标签名，应写成 <h2> 这类转义形式，避免被误当成页面结构。

交接后确认边界，避免重复排查

缓存问题解决后，要明确哪些层已经处理、哪些层未处理。HTTPS 不保证安全无漏洞或排名，缓存刷新也不保证搜索引擎立即更新摘要。不同搜索引擎对缓存和索引的处理方式不同，须分别核查。

下一步：把上面清单中的“响应头检查”和“缓存键检查”先填完，再决定是否需要开发介入改配置。如果两项都正常，问题可能不在缓存层，应转向数据源或发布流程。