给站点接入 CDN 之後，訪問速度通常會有明顯改善，但也會带来一類不容易察觉的問题：頁面明明已经改過，訪客看到的還是舊版本；某些地区的节点返回内容和源站不一致；蜘蛛抓到的頁面和目前實际内容對不上。這些情况未必是 CDN 出故障，更多时候是缓存策略和内容更新流程没有對齐。
先弄清楚谁在缓存什么
CDN 缓存的對象不只是 HTML。图片、CSS、JS、字体文件、接口返回的 JSON，甚至错誤頁面都可能被缓存。不同類型资源的合理缓存时長差別很大：带版本指纹的静態资源可以放心缓存較長時間；HTML 通常需要較短缓存，或者配合主動刷新；接口資料則要更谨慎，尤其是和登入態、库存、價格相關的内容。
還要区分浏览器缓存和 CDN 邊缘缓存。两者叠加时，排查會變得更麻烦——你刷新了 CDN，訪客本地可能還留着舊文件；你让訪客清了浏览器缓存，邊缘节点上可能還是舊的。
常见的缓存問题
- HTML 被設定了過長的缓存時間，内容更新後訪客仍看到舊頁面。
- 错誤狀態碼被缓存，比如 404、500 被节点记住，源站修好後依然返回错誤。
- 带查询參數的 URL 被当成完全不同的资源，缓存碎片化，命中率低。
- 個性化内容或登入態頁面被缓存，不同用戶看到同一份資料。
- 只刷新了部分节点，出現新舊内容並存的過渡狀態。
這些問题單獨看都不算嚴重，但叠加在一起，很容易演變成“我明明改了，為什么没生效”的反复拉扯。
一份可执行的检查清單
- 列出需要缓存和不應该缓存的资源清單，寫清楚每類的预期缓存时長。
- 查看响應头：Cache-Control、Expires、ETag、Vary、Age 等字段是否符合预期。
- 用不同地区、不同網絡环境訪問同一 URL，對比返回内容和响應头。
- 查看回源日誌，關注回源比例和回源原因，判断是否異常。
- 確認刷新和预热流程可执行，知道在哪里操作、大概多久生效。
- 检查错誤頁、跳轉頁是否被缓存，避免舊狀態長期驻留。
刷新動作要跟着更新节奏走
發布新文章、修改标题描述、更換模板或調整栏目结构之後，最好有明确的刷新動作，而不是“改完就等它自己過期”。常见做法是让 HTML 使用較短的邊缘缓存時間，配合發布後主動刷新；静態资源則用文件名或路径加版本号，實現新版本自然生效、舊版本自然淘汰。
如果站点内容更新频繁，可以把刷新流程寫進發布清單，谁改内容、谁负责刷新、多久確認一次，都提前说清楚，避免依赖個人记忆。
回源压力和蜘蛛抓取的關系
缓存命中率低，意味着蜘蛛每次抓取都要回源，源站压力大、响應變慢，抓取频率也可能受影响。合理的缓存設定能减少不必要的回源，让源站把资源留给真正需要的請求。但反過来，也不该為了降低回源就把不该缓存的内容缓存住，尤其是错誤頁和個性化頁面。
缓存的目标是让正确的内容更快到達訪客和蜘蛛，而不是把問题暂时藏起来。
換 CDN 服務商、增加节点、調整源站结构之後，建议重新過一遍上面的清單。缓存策略不是一次配置就永久有效的東西，它會随着站点结构、内容节奏和技術栈一起變化。把它当成站点运营里的常規检查項，比出了問题再临时排查要從容得多。