你在后台改了一段文字，保存，打开网站——还是旧的。再改一次，还是旧的。开始怀疑是不是没保存上。
这件事几乎每个管过网站的人都遇到过，而且很容易在上面浪费半小时。原因通常不是你没改对，而是你和服务器之间隔着好几层缓存，每一层都可能存着旧版本。
下面按从近到远的顺序排查。这个顺序很重要——从最近的一层开始查，能最快排除。
第零层：你确实改的是同一个地方吗
先排除这个，因为它比想象中常见。
双语网站改了中文没改英文、改的是草稿没发布、改的是另一个相似的页面、后台开了两个标签页覆盖了自己的修改。这些听起来低级，但在页面多的网站上很容易发生。
确认方法：在你改的那段文字里临时加一串独特的字符，比如 ZZTEST123，保存。后面每一步都搜这个字符串，能立刻分辨。查完删掉。
第一层：浏览器缓存
最近的一层，也是最常见的元凶。
浏览器会把页面和资源存在本地，下次访问直接用本地的。样式和脚本尤其容易被存很久。
怎么排除：用无痕窗口打开。无痕窗口不用现有缓存，如果这里是新的，那问题就在你的浏览器，其他访客看到的是正常的。
硬刷新（Ctrl+Shift+R 或 Cmd+Shift+R）也可以，但无痕更彻底，而且不影响你自己的浏览习惯。
如果无痕里也是旧的，继续往下。
第二层：CDN 边缘缓存
如果你用了 Cloudflare 之类的 CDN，它会在离访客近的节点存一份。
怎么确认：在网址后面加一个随机参数，比如 ?x=12345。带参数的地址通常不在缓存里，会直接回源。如果加了参数就是新内容，那就锁定是 CDN 缓存。
这个方法很好用，因为它同时排除了浏览器缓存（新地址浏览器也没存过）。
怎么解决：在 CDN 后台清缓存。但更该做的是想一下为什么它没自动失效——正常情况下改内容应该触发清除。如果每次都要手动清，说明自动化那一环没做，迟早会忘。
第三层：网站自己的页面缓存
很多系统会把生成好的页面存成文件，下次直接发文件，不再走一遍程序。WordPress 的各种缓存插件都是这个原理。
怎么确认：看响应头里有没有缓存插件加的标记（不同插件名字不同），或者直接去后台点一下”清除缓存”，然后再看。
这一层最容易出的问题是”清除规则漏了”。比如你新加了一个模板文件，但缓存的失效清单里没有它，于是改模板不会触发清缓存。表现就是”改了没反应”，而且怎么改都没反应。
我们自己犯过这个错：新增的模板没进监视列表，部署完线上纹丝不动，排查了一阵才想到。这类问题的特征是它不报错，一切看起来正常，只是内容不更新。
第四层：服务器端的对象缓存
比页面缓存更深一层，缓存的是数据库查询结果。改了内容但查询结果还是旧的，页面重新生成也是旧数据。
这一层不常见，多数中小网站没配。如果前三层都排除了还是旧的，问一下你的技术人员有没有开这个。
第五层：静态站没重新发布
如果你的网站是静态生成的——页面提前生成好、访客拿到的是文件——那么在后台改内容不会自动更新线上，必须重新生成并发布。
这不是 bug，是这种架构的固有特性。但如果没人跟你说清楚，你会以为是缓存问题，怎么清都没用。
我们自己的站就是这样，所以流程被固定成两步：改完内容，跑一条发布命令。这一步写在文档里，因为忘了这一步的表现和缓存问题一模一样。
一个附加情况：CDN 缓存了 404
这个值得单独说，因为它的表现很反直觉。
场景是：一张图片还没上传，有人（或者爬虫）访问了那个地址一次，CDN 记住了”这里是 404″。之后你把图片传上去了，访客看到的还是空白——因为 CDN 还在发那个记住的 404。
你会反复检查图片是不是传对了、路径是不是写错了，而这两样都没问题。
我们踩过两次，第二次才反应快。识别方法还是加随机参数：如果 图片地址?x=1 能正常显示，而原地址是 404，那就是缓存问题，清一下就好。
把这个顺序记下来
无痕窗口 → 加随机参数 → 清网站缓存 → 问对象缓存 → 确认要不要重新发布。
五步，每一步都是几十秒的事，走完基本能定位。关键是按顺序走，不要跳。大部分人在这上面浪费时间，是因为一上来就去清 CDN 缓存，而问题其实在自己浏览器里。
另外一条经验：如果你发现自己经常要手动清缓存，那是个信号。正常情况下内容变更应该自动触发失效，需要人记得的环节迟早会被忘掉。这件事值得让技术人员修一次，而不是每次手动处理。
我们交付的项目里，缓存失效是跟着内容变更自动跑的，不需要客户记得清。如果你现在的站要靠手动清，可以问问对方为什么。