缓存是為了让訪問更快、回源更少，但它也會把某一刻的狀態固定下来。站点运营中常见的“我明明改了，怎么還是舊的”，多數不是發布没生效，而是缓存還在用舊副本。下面這套自查不做复杂配置，只確認几件容易漏掉的事。
先列出哪些地址被缓存
不同類型的资源，缓存策略不该一样。先把站上會被缓存的地址分個類，再逐類確認。
- HTML 文档：更新最频繁，缓存時間通常最短，發布後往往需要主動刷新。
- 静態资源：CSS、JS、图片、字体适合長缓存，但要靠文件名或版本号變更来触發更新。
- 接口與 JSON：確認是否被 CDN 或浏览器缓存，避免前端展示舊資料。
- 错誤頁與跳轉：404、410、301、302 是否被長時間缓存，這是最容易踩坑的地方。
- robots.txt、sitemap.xml、RSS：這些文件會被反复讀取，缓存過久會让規則與地址清單滞後。
三個高频問题
狀態碼被一起缓存
頁面在上线前的短暂 404，或者一次誤配的 301，如果带着長缓存头返回，缓存节点會把這份答案留着。後續内容恢复了、跳轉改對了，来訪者與抓取工具拿到的仍是舊狀態。自查时用 curl -I 分別請求一個正常地址、一個已知不存在的地址和一個重定向地址，看它們的 Cache-Control 與 Age 是否合理。
缓存键與查询參數
同一内容如果带着不同參數被反复請求，可能生成多份缓存副本，既占空間也模糊命中統計。反過来，如果缓存键忽略了關键參數，A 參數的内容會被 B 參數的請求命中。先確認缓存键包含哪些部分，再决定要不要在入口层把參數收敛掉。
刷新與回源
發布流程里要有一句明确的“刷新哪些地址”。只刷首頁通常不够，列表頁、詳情頁、栏目聚合頁往往各有缓存。也可以用版本化文件名让静態资源自然過期，减少手工刷新带来的遗漏。
一頁自查清單
- 用 curl -I 查看响應头中的 Cache-Control、Age、ETag、X-Cache 等字段，判断副本来自哪一层。
- 對比带參數與不带參數的同一地址，看返回内容與缓存狀態是否一致。
- 检查 404、410、301、302 是否带有長缓存，必要时缩短。
- 確認 robots.txt、sitemap.xml 的缓存時間在可接受范围内。
- 改動發布後，按清單刷新相關地址，並再次請求核對實际返回。
- 把回源日誌與 CDN 命中統計對照，观察是否出現異常的回源量或缺失的记錄。
缓存不是問题，不确定缓存里放的是哪一版才是問题。把“改了哪里、刷了哪里、怎么確認”寫進流程，比临时清一次缓存更省事。
建议每季度做一次，在大改版、換域名、調整目錄结构之後更要补做。確認這几件事，站点在訪問速度和内容一致性上都會更可控。