缓存和 CDN 是把站点變快的好工具，但它們也是「看不见的中間层」。很多运营問题最後排查下来，並不是頁面寫错了，而是缓存给用戶和搜尋蜘蛛發了一份過期副本。

缓存出問题时，通常長什么样

• 後台改了标题或正文，前台刷新還是舊内容，過几小时才恢复。
• 上线新栏目，自己能看到，別人打開却是 404 或舊頁面。
• 不同地区、不同網絡訪問到的版本不一致，内容看起来「随机」變化。
• 蜘蛛抓到的頁面里，連結指向的却是早已下线的地址。

這些現象的共同点是：源站的改動已经生效，中間层還在交付舊结果。排查时先分清是源站缓存（頁面缓存、對象缓存）還是邊缘缓存（CDN），能省下不少時間。

自查一：頁面缓存與過期時間

先確認被缓存的對象是谁、缓存多久。

• HTML 頁面是否被整頁缓存？過期時間（TTL）设成多少？
• 登入用戶、购物车等個性化頁面是否被誤缓存？
• 後台發布内容後，是否有自動清理對應 URL 缓存的机制？
• 首頁、列表頁這類更新频繁的頁面，TTL 是否過長？

一個常见做法是：詳情頁缓存久一点，首頁和栏目列表頁短一点，並在内容發布、修改、刪除时主動刷新相關 URL。不要依赖「等它自己過期」。

自查二：CDN 規則是否和站点结构匹配

CDN 的預設規則往往是「缓存所有可缓存资源」，小站点問题不大，结构复杂时容易出错。

• 動態接口、站内搜尋頁、带參數的篩選頁是否被排除在缓存之外？
• 是否把 404 和跳轉响應也長期缓存了？這會让已修复的地址繼續报错。
• 回源配置里，源站 IP 變更後是否同步更新？
• 是否正确传递原始协议與主机名，避免出現混合内容或错誤重定向？

缓存的預設行為是「尽量少回源」。如果你没有明确告诉它什么不能存，它就會按自己的理解来。

自查三：蜘蛛收到的和用戶看到的是否一致

有些站点會對不同 User-Agent 返回不同内容，本意是優化，實际容易出問题。

• 確認没有對搜尋蜘蛛返回简化版或纯静態的舊快照。
• 確認 CDN 没有把某個 UA 的响應缓存下来，再分發给其他訪問者。
• 確認缓存里的 HTML 中，内鏈指向的是目前有效 URL，而不是歷史版本。

判断方法很简單：用命令行或抓取工具請求同一個地址，對比源站直连和经過 CDN 的结果，看狀態碼、标题、正文關键段落是否一致。

自查四：静態资源要带版本标识

图片、CSS、JS 這類文件通常缓存時間很長，靠文件名区分版本最省事。

• 资源地址里是否带有哈希或版本參數，例如 style.a1b2c3.css？
• 改版後是否生成了新的资源地址，而不是直接覆盖舊文件？
• 舊的资源文件是否還被其他頁面引用？

如果直接覆盖同名文件，用戶和缓存都可能繼續用舊版本，出現样式错乱、按钮点不動這類看起来像前端故障的問题。

一份可落地的检查清單

1. 列出站点里所有會缓存内容的层：應用缓存、對象缓存、CDN、浏览器缓存。
2. 為每一层寫下缓存對象、過期時間、清理方式。
3. 發布流程里加一步：内容上线後主動刷新對應 URL 與相關列表頁。
4. 改版或迁移前，先確認 CDN 與缓存規則是否需要同步調整。
5. 每次大改動後，用直连與 CDN 两條路径各驗證一次關键頁面。

把缓存当成流程的一部分

缓存規范不需要寫得很复杂，關键是有人负责、有地方记錄。把「發布後刷新哪些地址」「资源變更怎么命名」「異常时先看哪一层」寫進站点运维文档，比出事之後一层层试要高效得多。

最後提醒一句：缓存是加速手段，不是發布机制。内容是否被訪問到、是否被正确识別，最终還是要以源站的真實响應為准。