清完缓存还是旧页面，问题多半不在缓存

“我缓存都清了，清完怎么还是缓存还旧上周的价？”同事把笔记本转过来，页面上那个数字确实没动。页面我让他先别急着再点一次清理，问题打开开发者工具的多半网络面板，勾上“停用缓存”刷新——还是不缓旧的。到这一步，清完问题基本可以确定：他一直在跟一个并不存在的缓存还旧“缓存”较劲。

浏览器缓存这件事，页面误会往往不在操作难度，问题而在对“缓存”指代范围的多半想象。下面拆三个最常见的不缓误判，再给一套能照着走的清完排查顺序。

误会一：清缓存等于服务器上的缓存还旧内容会立刻变

这是最普遍的一层。很多人以为清掉本地缓存，页面浏览器就会去拿“最新”的页面。但缓存控制本质上是服务器说了算：响应头里写了多长的有效期，浏览器就按这个期限保存；有的资源甚至带着版本号或哈希值，文件内容换了，地址也换了，旧地址本来就该返回旧内容。

所以会出现一种典型场面：你在后台改了文章标题，前台刷新还是旧的，清缓存也没用。这时候打开网络面板看那条请求的状态码，如果显示 304，说明浏览器确实去问了服务器，服务器回答“没变，用你手里的”。问题在服务端或中间层，不在你的清理动作。反过来，如果显示 200 但内容仍旧，那要看是不是被 CDN 或反向代理缓存住了，这已经超出浏览器范围。

判断标准很简单：清缓存后仍不变，且请求确实发出去了，就把注意力从浏览器移开。下一步该找的是发布流程、CDN 刷新或者接口返回，而不是反复清本地。

误会二：所有“旧”都是缓存造成的

第二个误会更隐蔽：把登录态、接口数据、页面脚本的运行结果统统算进缓存的账上。有人换了账号，头像还是上一个人的；有人改了筛选条件，列表纹丝不动，于是又去清缓存。实际上，前者可能是本地存储里的会话信息，后者可能是前端把结果存在了内存或 IndexedDB 里，这些和 HTTP 缓存是两套机制，清理入口也不一样。

我见过一个反例：某后台页面每次打开都显示昨天的人数，运营坚持认为是缓存，清了一遍又一遍。后来在应用面板里一看，数据被脚本写进了 localStorage，还带了个“当天只拉一次”的标记。这类问题清浏览器缓存当然无效，得清站点数据，或者干脆用无痕窗口开一次做对照。

无痕窗口是个很实用的分诊工具：无痕下正常、普通窗口异常，多半是本地存的东西在作怪；两边都异常，才更可能是服务端或网络层。这一步花不了一分钟，能省掉很多无效清理。

正确顺序：先定位，再决定清什么

把顺序倒过来，效率会高很多。第一步，强制刷新一次，看现象是否变化；第二步，开无痕窗口访问同一地址；第三步，打开开发者工具，勾选停用缓存再刷新，同时看网络面板里那条关键请求的状态码和响应头。三步下来，问题大致落在“浏览器本地”“中间缓存”“服务端”三个格子里，再动手也不迟。

清理时也要分清对象。常规的“清除浏览数据”针对的是 HTTP 缓存和部分站点数据；只想解决单个站点，可以在站点设置里单独清；只想绕过缓存做一次验证，用停用缓存或强制刷新就够，不必把整台机器的缓存清空。顺带说一句，关于浏览器缓存的常见误区，很多都源于把“清得越狠越有效”当成默认前提，实际恰恰相反——范围越大，越难判断是哪一步起了作用。

一张自查小表，照着对就行

现象一：清缓存后仍旧，请求状态 304。判断：服务端认为没更新。下一步：查发布和版本号。

现象二：无痕正常，普通窗口异常。判断：本地存储或扩展干扰。下一步：清该站点数据，逐个停用扩展试。

现象三：换了账号信息还串。判断：会话或本地键值未更新。下一步：退出重登，检查应用面板里的存储项。

现象四：只有某台设备旧。判断：该设备的中间层或本地状态。下一步：换网络、换浏览器对照。

这张表不保证覆盖所有情况，但能挡掉大部分无效操作。真遇到发布系统、CDN 配置层面的问题，该找运维或开发就找，自己在浏览器里点清理是解决不了的。

回到开头那位同事，最后发现是接口返回被上游缓存了半小时，和浏览器一点关系没有。缓存是个好东西，前提是我们知道自己在清什么、为什么清。下次再遇到旧页面，先看一眼请求去了哪里，比连点三次清理更接近答案。