很多站点接入 CDN 之后，首页打开确实快了，但随之而来的是一类很难复现的问题：访客说看到的是昨天的价格，运营说后台明明改过了。这种情况大多不是程序出错，而是缓存层和源站不同步。缓存本身没有问题，问题在于没人定期检查缓存规则，也没人确认蜘蛛抓到的版本和访客看到的是不是同一份。
先分清哪些内容可以缓存
缓存策略的第一步不是调参数，而是给页面分类。
- 可以长期缓存：图片、样式表、字体、带版本号的脚本文件。这类文件内容基本不变，缓存久一点反而省事。
- 可以短缓存：栏目列表页、文章列表页。更新频率不高，缓存几分钟到几十分钟通常够用。
- 不建议缓存：登录后的个人中心、购物车、订单页、站内搜索结果页、带随机参数的页面。这类页面一旦被缓存并分发给别人，就不只是体验问题。
判断标准很简单：同一个 URL，不同用户看到的内容是否应该完全一样。如果答案是否，那就不该进公共缓存。
容易被忽略的三个细节
Cookie 与 Vary 头
有些页面会在响应里下发 Cookie，比如统计用的追踪标记、AB 测试分组。如果缓存配置忽略了 Vary 头，缓存服务器可能把一个带 Set-Cookie 的响应复用给其他访客。检查时可以用命令行工具请求同一个 URL 两次，看第二次是否带了 age 或命中标记，同时观察响应头里有没有不该出现的 Cookie。
缓存键与 URL 变体
末尾斜杠、大小写、跟踪参数都会生成不同的缓存键。同一篇文章可能被缓存成好几份：带斜杠一份、不带斜杠一份、带推广参数一份。结果不仅浪费缓存空间，还可能让蜘蛛顺着这些变体爬出重复内容。建议在服务器或 CDN 层把大小写、末尾斜杠统一，把常见的跟踪参数从缓存键里剔除，同时配合 canonical 指向规范地址。
TTL 与主动刷新
只依赖 TTL 自然过期，是很多站点更新之后内容迟迟不生效的原因。发布重要页面或修正错误之后，应当主动刷新对应 URL 的缓存，而不是等半小时。首页、栏目页这类入口，更值得在发布流程里固定加一步刷新操作。
别忘了蜘蛛看到的版本
缓存不只影响访客，也影响抓取。常见的坑包括：CDN 对陌生 UA 弹出验证码，蜘蛛直接拿到验证页面；地区节点策略导致特定地区的爬虫请求失败；错误页面被缓存后长时间返回 200 状态码。这些情况在浏览器里几乎看不出来，只能靠日志和模拟请求发现。
- 用不同 UA 请求核心页面，确认返回的是正常正文，而不是验证或跳转页面。
- 在 CDN 日志或源站日志里确认状态码分布，200 之外的比例是否异常。
- 检查是否有节点缓存了 5xx 或空白页，并把它当成正常页面长期返回。
一份可执行的缓存自查清单
- 列出全站页面类型，逐类标注缓存时长或不缓存。
- 抽查首页、栏目页、文章页各一条 URL，对比源站与 CDN 返回的内容和响应头。
- 确认带参数的 URL 不会被缓存成独立页面，或被统一重定向到规范地址。
- 确认发布流程里包含主动刷新缓存这一步。
- 翻一遍近期日志，看看有没有大量 403、503 或验证页记录。
- 改动缓存规则后，先在小范围路径验证，再全量生效。
缓存的目标是让重复请求更快，而不是让内容停留在过去。任何一次改版、调价、修正文章，都应该先问一句：缓存刷新了吗？
把它变成流程而不是救火
缓存问题最麻烦的地方在于它是间歇性的，只有部分用户或部分节点会碰到，排查成本很高。与其等出了问题再临时清缓存，不如把检查写进发布流程：内容改动后刷新指定 URL，规则调整后按路径灰度，每月定期抽查一轮首页和栏目页的实际返回内容。做完这些，缓存带来的收益会稳定得多，蜘蛛和访客看到的也会是同一份页面。