4.2 缓存与刷新：更新文章后首页没变怎么办

某天晚上九点多，朋友急吼吼地给我发消息：“产品页改了三遍了，前台还是旧的，我是不是改了个寂寞？”远程一看，后台文章明明更新了，前台首页的产品介绍还是昨天的内容。这是建站后最高频的一类问题，根源是缓存——而且是叠了两层的缓存。这一节把缓存的结构、配置和刷新操作一次讲清楚，以后再遇到就知道从哪查起。

两层缓存结构：先分清锅是谁的

朋友这种情形，可能性无非三种：浏览器本地缓存、WordPress 自己的缓存插件、CDN 节点缓存。排查顺序一定从离访客最近的开始往外排，否则改了半天方向都错了。我给他列了张对照表：

判断属于哪一层有个捷径：换个网络环境（比如手机切 4G）再访问一次。如果新内容出来了，说明是浏览器或本地 Wi-Fi 的缓存；如果还是没有，问题在服务器或 CDN 这侧。朋友的 case 两层都中：缓存插件生成的页面副本没清，CDN 又把旧 HTML 缓存住了，属于最难排查的那种。

最冤的一种情况要单独提一下：网站其实更新了，访客也看到了新内容，只有朋友自己一直在看旧页面——他的浏览器缓存和登录态跳过页面缓存两件事叠在一起，登录用户看到的本来就是给他的旧页面。那天他要不是截图发给我看，还以为网站坏了。所以后来我定了个规矩：验证更新一律用无痕模式，不拿自己的日常浏览器做判断。

又来一次：CSS 改了颜色却没生效

产品页那件事过了一个月，朋友又找我：“我把首页按钮颜色改成品牌蓝了，手机上看怎么还是绿的？”这次我熟门熟路，先让他无痕模式打开——颜色变了，问题在浏览器缓存。但他说客户的手机上也还是绿的，这就不是一个人的本地缓存能解释的了。查了一圈发现：主题的 CSS 文件名没有版本号机制，CDN 上那份旧 CSS 还在 7 天的 TTL 里慢慢耗，所有访客都得等它过期才能看到新版。

解法是双管齐下：先在 CDN 控制台按 URL 刷掉这个 CSS 文件，立刻生效；再给主题加上带版本号的文件名引用（多数主题和构建工具自带，WordPress 也有现成的函数可用），以后改样式文件名一变就自动绕过旧缓存，彻底告别手动刷。这件事让我意识到小站点的缓存配置也是个迭代过程：第一次按通用模板设，用一段时间后根据实际踩坑调整，最后沉淀成适合自己站点的策略。这套流程现在挂在朋友的浏览器收藏夹里，改一次内容点四下，再没半夜打过我的电话。

WordPress 缓存插件：分层和清理

WP Super Cache（或 WP Rocket、W3 Total Cache 等）把 WordPress 动态页面存成 HTML 副本，下次请求直接返回副本，不再查数据库。对小服务器来说这是省 CPU 的关键，但也意味着内容已变、副本没更新时，访客就会看到旧页面。关键配置有三处：

一是缓存过期时间。插件设置里一般有“缓存超时时间”，单位是秒，我设的是 3600 秒（一小时）。企业官网更新不频繁，一小时足够平衡性能和新鲜度；朋友那个产品页是当天临时上新的，等不了一小时，就手动清。

二是自动清理时机。勾选“当有新文章或页面发布时更新缓存”，WordPress 内容一变，插件自动重建首页这类聚合页。我一开始没勾这个选项，导致朋友的页面改了但首页旧副本还在——这就是他看到“没变化”的直接原因，勾上之后这类问题再没出现过。

三是排除规则。登录态的用户评论、留言表单的提交结果、带查询参数的页面，这些不能缓存，要在插件里排除掉，否则会出现访客看到别人评论的乌龙。

浏览器缓存：第一层也是最容易被忽略的一层

排查缓存问题永远从浏览器开始，因为它是唯一不归你管、但访客每天都在用的缓存。浏览器按响应头里的 Cache-Control 决定本地副本留多久：静态文件一般设几个月，HTML 通常设很短或不设。WordPress 缓存插件那边其实也会处理这些响应头，两边一叠加，偶尔会出现“服务器上明明是最新的、朋友死活刷不出”的情况。

我给朋友的操作动作分三档：普通刷新（F5）只重新验证，可能仍用本地副本；强制刷新（Ctrl 加 F5）绕过本地缓存向服务器或 CDN 重新取；最彻底的是开浏览器无痕模式——无痕模式不带历史缓存和已登录的 Cookie，等于模拟一个全新访客。我现在远程帮他排查，第一步永远是无痕模式打开，十次里有八次直接就看到新内容了，省下后面两层排查的功夫。给非技术的人解释这套逻辑有个比喻很管用：网站内容像超市货架上的商品，浏览器缓存是你自己家里的存货，插件缓存是超市的仓库，CDN 是各个分店，任何一个环节没补新货，你看到的就还是旧的。朋友听完这个比喻，终于不再觉得缓存是玄学了。

CDN 缓存：过期时间、刷新与预热

CDN 那边的缓存规则在控制台的缓存配置里，核心是按文件后缀设过期时间。过期时间的逻辑跟 WordPress 插件正好相反：插件怕缓存住旧内容，所以 TTL 设短；CDN 怕节点频繁回源，所以 TTL 设长。中间的桥梁是 4.1 节里插件改写的带版本号文件名——主题一改 CSS，文件名里的 hash 就变，等于新 URL 自动绕过旧缓存，这就是为什么 CSS、JS 可以放心设 7 天。我给的配置可以参考：

过期时间越长命中率越高，但内容更新就要靠手动。CDN 控制台提供两类操作，用法完全不同：

URL 与目录刷新是删旧缓存，适合改完内容立刻生效。选中刷新预热里的“缓存刷新”，可以按单个 URL（精确到某个文件）、按目录（比如 https://cdn.example.com/wp-content/uploads/2026/10/ 整个目录刷掉）、或按 URL 前缀批量提交。三种方式按改动范围从大到小选，能精确到单个文件的就别刷整个目录，每次刷新都有当日额度限制。更关键的是：别一激动整站刷——整站刷新意味着所有节点重新回源取文件，源站带宽会瞬间冲高，4M 带宽的小服务器扛不住这个峰值。

预热是相反方向的操作，主动把内容推到节点上，适合发版场景。前提是内容已经稳定，别把测试中的页面推得到处都是。服务器带宽小，每次集中更新后那几分钟首访体验都很差，后来我养成习惯：每次集中更新前先用预热把首页和热门产品页推到各节点，上线时访客基本无感。另外提一句预热和刷新的一个区别：刷新是删旧的，预热是提前填新的，两者别混着用——有人刷新完顺手又预热，等于刚清掉的旧文件又被推回去了（实际推送的是源站当前内容，不会推旧文件，但顺序颠倒会多花一次刷新额度）。

一个固定流程

被朋友连环问过几次之后，我给自己定了个更新流程，再没出过“改了没生效”的事：

四步走完两分钟搞定。麻烦的是另一种情况：朋友以为没更新，其实是改错地方了——他改的是草稿不是已发布页面。所以流程之外先确认后台的发布状态，再谈缓存。还有一个反向的坑：刷新太勤快。朋友有一阵养成习惯，每次更新都顺手点一下 CDN 的整站刷新，等于把辛辛苦苦攒的节点缓存全部清零，接下来几分钟所有访客都要回源取文件，4M 带宽的服务器直接被挤爆，首页加载时间反而比不接 CDN 的时候还长。刷新是武器不是日常用品：按目录、按改动范围精确刷，才是正确用法。

WordPress 缓存和面板相关的更多细节，可以翻服务器常见问题；网站做大后的性能架构思路，见腾讯云实战手记。

延伸阅读

• 服务器常见问题排查：从面板到建站故障
• 腾讯云实战手记：CVM、MySQL、COS、CDN 与短信五件套
• 网站加速与地域优化实践