做站点运营时，缓存常被当成纯技術問题：上线时配一次，出事再清一次。但缓存實际决定了用戶和搜尋蜘蛛拿到的是哪個版本。如果版本不對，前面做的栏目調整、内容更新、内鏈改動都可能被延後生效，甚至長期不生效，而运营侧看到的只是「發了没反應」。
缓存影响运营的三個位置
一是浏览器缓存，决定了回訪用戶多久才拿新頁面；二是 CDN 或反向代理缓存，决定了各地訪問者拿到的是不是同一份内容；三是服務端對象缓存、頁面缓存，决定了高峰时資料库压力和後端响應速度。三者只要有一處規則不一致，就會出現同一地址不同人看到不同内容的情况。
常见的缓存異常表現
- 文章已更新，頁面标题和正文仍是几天前的版本；
- 已下线的頁面仍能被訪問到，点進去還能看到舊内容；
- 错誤頁、维護頁被缓存，正常訪問时也返回同一提示；
- 带參數的地址各缓存一份，同一内容散出多個副本；
- 移動端與桌面端互相串版本，排版错位或跳轉異常。
自查清單
- 区分资源類型设时長。带指纹的静態资源（CSS、JS、图片）可以设長缓存；HTML 頁面建议短缓存或协商缓存，避免發布後長時間不更新。
- 检查缓存键。確認缓存键是否包含主机名、路径、必要的查询參數。參數被無差別纳入，會放大重复副本；參數被全部忽略，又可能让不同内容互相覆盖。
- 確認 Vary 头。按设备或語言返回不同版本时，要看响應头是否声明了對應的区分维度，否則容易串版本。
- 排除错誤頁與重定向。让 4xx、5xx 以及临时跳轉尽量不被長時間缓存，避免故障期過後仍返回舊结果。
- 核對登入態與個性化内容。涉及用戶狀態的响應不應進入公共缓存，防止内容错位。
- 看清缓存层級。浏览器、CDN、服務端各自有開關，清一层不代表全部清掉。
發布後的驗證流程
内容上线後，至少做三步驗證：用無登入態的方式確認首屏内容是否為新版本；查看响應头里的缓存狀態字段，判断是命中缓存還是回源；從不同網絡环境或节点再取一次，確認各层结果一致。若發現仍是舊版本，先定位是哪一层命中，再决定是清指定地址還是刷新整批资源。
提醒：清缓存不是越勤越好。频繁全量清除會让回源压力集中上来，反而拖慢高峰期响應。更稳的做法是按栏目或按批次清理，並给静態资源加版本指纹，让新文件走新地址。
把缓存規則寫進日常流程
建议在运营發布清單里固定几項：本次改動涉及哪些地址、這些地址是長缓存還是短缓存、是否需要清缓存、清完由谁驗證。改動較大的栏目，可以先观察一小批地址的抓取與訪問情况，確認版本一致後再扩大范围。
缓存本身不产生排名，但它决定了你改動的内容能不能按时被看到。把缓存当成發布流程的一环，而不是故障後的补救動作，站点运营的节奏會稳定很多。