CDN 的價值是把内容放到离用戶更近的节点上，但如果缓存規則配得過于粗放，就會出現一種很常见的尴尬：源站的頁面已经改好，用戶和搜尋引擎拿到的仍然是几小时甚至几天前的舊版本。缓存本身不是問题，問题在于缓存的時間、范围和失效方式没有跟着内容节奏走。
先分清哪些资源适合長時間缓存
不同资源的更新频率差別很大，用同一套規則去套，通常不是太保守就是太激進。可以先按類型分档：
- 静態资源：带哈希文件名或版本号的 JS、CSS、字体、图片，内容一旦生成就不再變化，适合設定較長的缓存時間。
- 媒体文件：视频、大图、附件，体积大、回源成本高，适合長缓存，但需要注意替換同名文件的场景。
- HTML 文档：栏目頁、詳情頁、首頁，内容随时可能調整，缓存時間要短，或者配合主動刷新使用。
- 接口與動態資料：一般不建议在邊缘节点長期缓存，除非能接受短暂的資料滞後。
缓存自查清單
1. HTML 文档的 TTL 是否過長
有些站点為了压低源站压力，把 HTML 也设成几小时甚至一天的缓存。结果是編輯改完标题、补完内容，頁面在浏览器里刷新還是老样子，只能靠手動刷新缓存救场。如果内容更新較频繁，建议把 HTML 的 TTL 控制在較短区間，或者對首頁、栏目頁單獨設定更短的時間。
2. 缓存键是否把不该合並的 URL 合並了
缓存键决定了哪些請求被视為“同一個頁面”。如果規則忽略了全部查询參數，那么带篩選、带排序、带跟踪參數的 URL 都可能命中同一個缓存副本，用戶点進不同篩選條件看到的内容却完全一样。反過来，如果把所有參數都算進缓存键，又會生成大量只訪問過一次的缓存碎片，命中率大幅下降。常见的折中做法是保留有业務含义的參數，忽略纯跟踪類參數。
3. Vary 头有没有遗漏關键维度
如果站点為移動端和桌面端返回不同的 HTML，却没有在响應头里声明按 User-Agent 区分，就很可能出現移動用戶拿到桌面版缓存、桌面用戶拿到移動版缓存的情况。压缩方式（Accept-Encoding）通常也需要声明，否則可能出現内容编碼错乱。這一項在移動優先的抓取环境下尤其值得检查。
4. 刷新與预热是否覆盖了真正改動的頁面
發布内容後，只刷新首頁往往不够。列表頁、标簽聚合頁、相關推荐位都可能引用到新内容，需要一並處理。對于重点頁面，可以在發布後主動预热，把内容提前推到节点上，避免第一個訪問者承担回源等待。
5. 回源策略是否给源站留了余地
当大量缓存同时過期时，請求會集中打回源站，形成短時間的回源高峰。可以關注回源超时時間、重试次數、並發限制這些參數，避免源站在流量尖峰时被自己人打满。源站响應變慢，邊缘节点也會跟着變慢，最终体現在抓取和用戶体驗上。
怎么驗證缓存是否按预期工作
- 用命令行工具查看响應头，關注缓存命中狀態、缓存年龄、缓存控制字段是否符合预期。
- 從不同地区或不同網絡請求同一個 URL，對比返回内容與源站是否一致。
- 挑一個測試頁面做小改動，记錄各节点更新所需的時間，形成自己的经驗值。
- 查看缓存命中率和回源比例，判断規則是否過于保守或過于激進。
- 抽查站点地图中的重点 URL，確認它們返回的是目前版本，而不是歷史副本。
几個容易被忽略的细节
刷新缓存不等于内容一定更新。如果源站自身還有一层頁面缓存、對象存储副本或模板缓存没有同步，邊缘节点回源拿到的依然是舊内容。排查时要顺着鏈路從源站到邊缘逐段確認，而不是只盯着 CDN 控制台。
- 替換同名图片或附件时，長缓存會让舊文件繼續被使用，建议改用带版本号的新文件名。
- 站点改版後，舊路径如果被缓存，可能在重定向生效前繼續對外服務一段時間。
- 错誤頁面也可能被缓存。如果某次回源失敗返回了错誤頁，需要確認它不會被当作正常内容長期存放。
小结
缓存策略的目标不是“缓存得越多越好”，而是让每類资源在合适的時間内被复用。把资源分類、TTL、缓存键、Vary 头、刷新與预热這几項過一遍，多數“改了没生效”的問题都能找到出處。