内容更新上线後，最容易出現的一種错觉是：後台已经發布，編輯自己刷新也看到了新版本，就預設所有人都看到了。實际上，訪客、蜘蛛、不同地区的用戶，可能還在從浏览器缓存或 CDN 邊缘节点讀取舊頁面。缓存本身不是坏事，它让站点更快、更稳、更省钱，問题在于更新时没有把缓存的邊界和清理顺序想清楚。
先分清有哪几层缓存在起作用
一個請求從用戶到源站，通常會经過多层缓存。排查“為什么還是舊内容”时，按层往下找，比反复点發布按钮有效。
- 浏览器缓存：用戶设备上的副本，受 Cache-Control、Expires、ETag 等响應头控制。
- CDN 邊缘缓存：离用戶最近的节点缓存，命中後可能完全不回源站。
- 反向代理與頁面缓存：Nginx、Varnish、部分 CMS 插件生成的静態化頁面。
- 對象存储與附件缓存：图片、CSS、JS、下载文件的缓存。
這几层的過期時間往往不一样。静態资源可以设很長，HTML 頁面通常不适合设太長，否則發布後要等很久才生效。
更新後该清理哪些地址
很多人只清了首頁，结果栏目頁、列表頁、标簽頁還是舊内容。建议把需要刷新的地址分成几组：
- 本次直接改動的詳情頁。
- 會引用它的列表頁、栏目頁、首頁。
- 站点地图、RSS、搜尋结果頁等自動生成頁面。
- 带版本号或指纹的静態资源，如果文件名没變，也要一起刷新。
清理顺序建议是：先確認源站已经更新，再清 CDN，最後通知浏览器重新驗證。如果源站還没更新就清 CDN，邊缘节点回源拿到的仍然是舊内容。
缓存键决定了命中范围
缓存键不只是 URL。查询參數、Cookie、請求头、设备類型、地区都可能參與缓存键。參數越多，缓存命中率越低；參數太少，又可能把不该缓存的内容混在一起。
- 带登入態的頁面不要做公共缓存，否則可能把 A 用戶的信息给到 B 用戶。
- 篩選、排序、分頁參數如果會出現在缓存键里，要评估是否需要缓存，避免生成大量低價值缓存副本。
- Vary 头設定不当，可能让同一個地址在缓存里裂成很多份。
比較稳妥的缓存策略
静態资源（带内容指纹的 CSS、JS、图片、字体）可以設定較長缓存，文件名變化时自然更新。HTML 頁面更适合短缓存加协商缓存，让浏览器和 CDN 在過期後回源驗證。
列表頁和首頁更新频繁，缓存時間可以比詳情頁更短，或者發布时主動刷新。sitemap、RSS 這類文件如果被長時間缓存，可能影响新内容的發現，建议使用較短的缓存時間，並在更新後主動清理。
缓存的目标不是“永遠不缓存”，而是让该快的快、该新的新。更新流程里如果没有缓存刷新這一步，就等于把缓存当成了不可控變量。
別為了蜘蛛抓取把缓存整体關掉
有时會發現蜘蛛抓到的還是舊頁面，于是干脆關閉 CDN 缓存。這样做短期看似解决問题，長期會让源站压力上升、响應變慢，反而影响抓取效率。更合理的做法是：给 HTML 設定合理短缓存，保證蜘蛛多次訪問时能拿到較新版本；同时通過 sitemap、内鏈和主動提交，让新地址更快被發現。
蜘蛛是否抓到新内容，受抓取频率、頁面權重、缓存時間共同影响。缓存只是其中一個因素，不要把它当成唯一開關。
一份可以照着做的自查清單
- 發布後抽查首頁、栏目頁、詳情頁，確認源站和 CDN 返回一致。
- 用 curl -I 或浏览器開發者工具查看 Cache-Control、Age、X-Cache 等响應头。
- 確認 sitemap、RSS 没有被長時間缓存，更新後能立即反映新地址。
- 检查带登入態、带用戶信息的頁面是否誤做公共缓存。
- 观察回源量和 5xx 错誤，避免缓存過期集中在同一時間造成回源尖峰。
- 把“刷新缓存”寫進發布流程，而不是靠记忆临时操作。
缓存配置不需要一次做到完美，但需要有一條清晰的更新鏈路：源站先變，缓存後清，最後驗證。把這几步固定下来，内容更新後“別人看到的還是舊頁面”這類問题會少很多。