先说结论，可能不少人已经知道了：WordPress 挂了对象缓存和 CDN 之后，清缓存的顺序要从最里层往外——先 Redis ，再服务器整页缓存（ Nginx FastCGI ），最后 CDN 。顺序反了，清了也白清。
我前阵子反复遇到一个场景：后台改完文章提示成功，前台打开还是旧内容。第一反应清缓存，一层两层三层全清一遍，还是旧的。加个 ?v=123 马上就新了，去掉参数又变回旧的。
折腾了一段时间才把链路想明白。
三层缓存各自的性格：
- CDN：缓存整页 HTML ，按 URL 做键，有自己的 TTL
- Nginx FastCGI cache：也是整页 HTML ，按 URL 做键，落在磁盘上
- Redis 对象缓存：缓存的是数据库查询结果。注意，它默认没有 TTL ，写进去就一直躺着，直到被显式删掉
坑就藏在第 3 条里：
- 你改了文章，数据库里已经是新内容
- Redis 里还是旧数据
- 这个时候有访客或者爬虫进来
- PHP 从 Redis 捞到旧数据，渲染出一份"全新的旧页面"，丢给 Nginx 缓存了起来
- 你事后去清缓存，就算把 Redis 和 Nginx 都清了，上面那份旧页面可能早被 CDN 吃进去继续对外发了
也就是说：清理动作的时机和顺序不对，反而会把旧内容"固化"一层。
为什么必须从里往外清：任何两步清理之间都有窗口期，窗口期进来的请求，会拿"还没清的那层"的旧数据，把"刚清完的那层"重新填满。先清外层的话，内层的旧数据一秒钟就把外层又填回去了。
判断卡在哪一层，我一般两个动作就够：
- 看响应头。curl -sI 页面地址，看 cf-cache-status / x-cache 之类的字段，确认这次命中的是哪一层
- 加随机参数对比。带参数的 URL 不会命中按 URL 缓存的层，所以：带参数是新的、不带是旧的，说明卡在 Nginx 或 CDN ；两个都旧，就是对象缓存或数据层；两个都新，那只是浏览器在骗你
再补一个容易走偏的点：如果响应头显示 MISS 、页面却还是旧的，那缓存是清白的，大概率是写入根本没成功。这个我踩过——折腾半天缓存，最后发现是保存流程没走完。
后来我把流程固定成这个顺序，基本没再翻过车：
先确认写入成功（直接读库里的字段，别信后台的提示）→ 清 Redis → 清 Nginx （能用按路径的定向清除就别整目录删）→ 清 CDN → 从源站直连抓一次比对，顺便预热 → 最后走公网再抓一次看响应头（可能还是 HIT ，正常，TTL 没到而已）。
还有两个边角：
- 浏览器缓存能骗过所有服务端清理，无痕窗口也要新开一个才算干净
- 有的 CDN 对静态资源会忽略查询字符串，?ver= 改版本号没用，只能改文件名或者整站清
详细的命令和这套顺序我整理成了文档放在自己站上（软件和运维的笔记站，就这一条自己链接，介意的可以略过）： https://gkmix.com/wordpress-cache-configuration/
最后想请教一个点：对象缓存这块，你们是每次改完手动清，还是挂了自动失效的钩子？我目前还是手动的，想看看有没有更省心的做法。
1
Select Language