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

网站缓存，怎样形成可复用检查清单

把网站缓存检查做成可复用清单，核心是固定“对象—方法—判据”三栏：每次只检查一类缓存对象，用同一条命令或同一个界面入口取证，再按明确阈值判断是否异常。这样换一个站点、换一个同事执行，结果仍然可比。

先分清要查的是哪一层缓存

网站缓存至少涉及四层，混在一起查就会得出错误结论。第一层是浏览器缓存，由响应头里的 Cache-Control、Expires、ETag 控制；第二层是CDN或反向代理缓存，决定静态资源是否命中边缘节点；第三层是应用层缓存，比如页面片段、查询结果、对象缓存；第四层是数据库或持久层缓存。检查清单的第一步，就是给每次排查标注层级，避免把“浏览器显示旧页面”直接归因于服务端。

可复用清单的六项固定检查

下面每一项都按“查什么—怎么查—结果说明什么”写，可以直接抄进团队文档。

1. 查响应头缓存策略。用浏览器开发者工具的Network面板或 curl -I 页面地址 查看目标资源的响应头。若 Cache-Control 为 no-store，说明该资源被要求完全不缓存；若为 max-age=31536000 且文件名带内容哈希，通常属于可长期缓存的静态资源；若HTML文档也设置很长的 max-age，发布后用户可能长时间看到旧内容，需要重点确认。
2. 查缓存命中与回源。在CDN控制台查看命中率、回源请求数和状态码分布，或用 curl -I 对比两次请求是否出现命中标识头（不同服务商标识头名称不同，以实际响应为准）。命中率长期偏低，可能是缓存键包含随机参数、Cookie参与缓存判断，或源站返回了不可缓存状态码。
3. 查URL参数与缓存键。给同一路径分别加上无意义参数（如 ?a=1、?a=2）请求，观察是否都回源。如果每个参数都生成独立缓存副本，说明缓存键过细，会稀释命中率并增加源站压力。
4. 查刷新与失效机制。发布新版本后，确认旧缓存是被主动清除、按TTL自然过期，还是靠文件名版本号绕过。三种方式适用条件不同：主动清除适合紧急修正，TTL适合可容忍延迟的内容，版本号适合静态资源。若没有任何失效手段，只能等过期，属于需要补上的缺口。
5. 查动态内容的缓存边界。登录态页面、购物车、个性化推荐不应被公共缓存。检查方法是退出登录后请求同一地址，看返回内容是否包含他人信息；同时确认 Vary 头是否正确区分了 Accept-Encoding 等维度。发现串号迹象时，应立即把该路径排除出公共缓存。
6. 查抓取与缓存的关系。robots.txt 的抓取限制不等于可靠的索引移除，它只约束爬虫抓取行为，不控制已经建立的索引，也不等同于缓存清除。站点地图也不保证收录。需要让搜索引擎更新缓存副本时，应使用对应搜索引擎各自提供的工具分别核查，不同搜索引擎的支持情况要分开确认。

把检查结果写成可判断的记录

清单可复用的关键不在项目多，而在每项都有可判断的结果。建议记录格式为：检查项、执行时间、请求地址、关键响应头或控制台数值、结论（正常/异常/待确认）、处理动作。例如“HTML文档 Cache-Control: max-age=600，发布后10分钟内用户可见新版本，符合预期”，就是一条可被下次直接比对的记录。若只写“缓存已检查”，下次无法判断是否退化。

什么时候可以跳过某些检查

纯静态站点且资源文件名带内容哈希时，第4项失效机制可以简化为确认版本号是否随构建更新；不涉及登录态的展示型页面，第5项可只做抽样。反过来，电商、后台系统、含个性化接口的站点不能省略第5项。判断依据是：该页面是否对不同用户返回不同内容。是，就必须查缓存边界；否，可以降低该项频率，但仍需在发布流程中保留一次确认。

下一步

先选一个当前正在维护的页面，按上面六项各执行一次并记录结果，把其中反复出现的两项固化为发布前必查项。等这份记录连续使用三次且结论稳定，再考虑扩展成覆盖全站的模板。