先说结论，可能不少人已经知道了：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/ 最后想请教一个点：对象缓存这块，你们是每次改完手动清，还是挂了自动失效的钩子？我目前还是手动的，想看看有没有更省心的做法。

  • 情报分类：服务器与云资源
  • 分类依据：内容涉及服务器、云资源或网络线路
  • 信息来源：服务器 / V2EX
  • 发布时间：2026/9/29 17:54:56