很多站点接入 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，規則調整後按路径灰度，每月定期抽查一轮首頁和栏目頁的實际返回内容。做完這些，缓存带来的收益會稳定得多，蜘蛛和訪客看到的也會是同一份頁面。