為什么缓存會成為运营變量
内容更新後，源站已经生效，訪客和蜘蛛却可能還看到舊版本。這通常不是“蜘蛛没抓”，而是缓存层没有同步。缓存本身是好事，它能降低源站压力、加快首屏；問题出在缓存策略不统一：有的节点缓存十分钟，有的缓存十二小时；有的頁面按 URL 缓存，有的還按 Cookie 或 UA 分版本。结果同一個地址在不同時間、不同节点返回不同内容，外部观察到的行為就顯得没有規律。
先分清有几层缓存
排查前把鏈路列清楚，通常至少三层：
- 浏览器缓存：由 Cache-Control、Expires 控制，影响的是回訪訪客。
- CDN 邊缘缓存：由节点規則、缓存键、TTL 决定，影响首次訪問的速度和内容版本。
- 源站或應用缓存：頁面缓存、對象缓存、資料库查询缓存等，影响更新是否能立刻反映。
三层里任何一层没跟上，外部看到的都可能不是最新内容。自查的重点，是確認這三层對同一個 URL 的判断是否一致。
几個容易踩的坑
HTML 被当成静態资源長缓存
图片、CSS、JS 長缓存没問题，因為文件名里通常带版本号。文章頁、栏目頁這類 HTML 如果也设了很長的 max-age，更新後訪客要硬刷新才能看到，蜘蛛也會在一段時間里反复看到舊内容。更稳妥的做法是给 HTML 較短的 TTL，配合 ETag 或 Last-Modified 做校驗。
缓存键忽略了關键差异
如果站点對移動端和桌面端返回不同模板，缓存键里就要包含對應的标识，並让 Vary 头與之一致；否則移動端訪客可能拿到桌面版頁面，或者反過来。同理，多語言、登入狀態、灰度分组都可能需要獨立缓存键。缓存键太粗，頁面會串；太细，命中率會掉，需要按實际差异决定。
错誤頁被缓存
源站抖動时返回的 5xx，或者某個不存在的路径返回的 404，如果在邊缘被缓存下来，就會持續對外輸出错誤頁。要检查 CDN 是否對 4xx、5xx 設定了短缓存或不缓存，並確認有對應的清理手段。
自查的几種做法
- 用命令行多次請求同一 URL，观察响應头里的缓存狀態字段（不同厂商命名不同，常见有 Age、X-Cache 之類），確認是否命中、TTL 還剩多久。
- 從不同地区或不同網絡發起請求，對比返回正文的關键片段是否一致，尤其是刚更新過的頁面。
- 更新一篇内容後，记錄源站生效時間、缓存清理時間、外部可见時間，连續做几次，找出平均延迟。
- 检查缓存規則里是否對 HTML、接口、图片分別設定了不同策略，避免一刀切。
- 確認清理流程有记錄：谁触發、清了哪些 URL、多久生效。
把確認動作放進更新流程
與其事後猜测，不如把“發布後確認外部可见”寫進日常流程。更新頁面少时手工核對即可；數量多时，抽样检查主栏目頁、新發布頁和被改動過的舊文。核對时重点看狀態碼、頁面标题、正文首段這三處，最容易發現拿到了舊版本。
缓存不是問题，缓存策略不一致才是問题。让每一层對“這個地址現在應该返回什么”有同一個答案，訪客和蜘蛛看到的内容才不會分叉。