土拨鼠日志：改了代码刷新还是老页面，多半不是没改到

这两天我栽在一个特别折磨人的坑里：一个页面怎么改都是空白，改了半天、清了缓存、甚至换了浏览器窗口才看到变化。明明代码已经是对的，用户看到的却是旧东西。今天就把「改了却看不到」这件事讲透——多数时候不是你没改对，是缓存把旧版死死攥住了。

一、假绿与假旧：先搞清楚「谁在骗你」

这一轮的教训里有个共通点：很多表面上「成功了」的信号，其实都是假象。

• 脚本打印了「写成功、大小 xxx」，结果读取回来发现文件根本没改——打印的是改动前的数；
• 任务显示运行状态「ok」，结果打开日志，该干的活一行没干；
• 改完前端，普通浏览器窗口打开是新的，无痕窗口打开却还是空白——因为旧缓存放大了这个差别。

所以第一课不是「改代码」，是改完必须读回目标物确认。别信脚本的 print，别信任务的 ok，去读回那个文件、那个页面、那个返回值，眼见为实。

二、看不见的手：缓存到底扣在哪儿

回到「刷新还是老页面」，缓存可能藏在三层：

• 浏览器层：给了长缓存头，或者靠「启发式缓存」自己推断——nginx 里一句 expires 30d，前端改了用户一个月都看不到；
• 中间层：CDN、反向代理把静态文件按原文件名缓存，文件名没变它就一直吐旧内容；
• 文件名层：打得最狠的是「文件名没变」。改内容但文件名照旧，所有缓存都不会失效。

最典型的一次：nginx 默认给所有 js 发了 30 天缓存，又不给 HTML 加 cache-control，浏览器就自己「看着办」地缓存。结果前端修了好几版，用户永远看到第一版。这不是 bug，是缓存策略没管好。

三、怎么让新版本立刻可见

对症下药，三条就够：

• 对不该缓存的入口（比如 index.html、首页、真正入口的 js）设 no-cache 或 must-revalidate，让它每次都跟服务器确认一眼；
• 对要长期缓存的静态资源，改了就让文件名变（加版本号或哈希），新名自然绕过所有旧缓存；
• 改完自己先读回验证一遍：抓线上正文确认真变了，再让用户刷新。

这里还有个反直觉的点：「修不好」的页面，有时候代码一直是对的，是你看它的那个窗口里的缓存骗了你。把它当「部署问题」查缓存，比当「代码问题」反复改要快得多。

四、土拨鼠里这套是怎么落地的

• 会经常更新的入口页面带 no-cache，改完刷新即见，不用等；
• 静态资源变更时文件名跟着变，避免长缓存吐旧货；
• 任何「改完」都以读回线上为准，报给你的都是验证过的结果，不是脚本的自我感觉。

想看整套能力是怎么组织的，翻 功能页；想算算值不值让它帮你管这些琐碎，定价页 有按量的对照；想直接上手，下载 装一个最直观。

五、留一条给你自己的自查

下次「改了却没变化」，先别急着再改代码，问一句：我现在看到的是新版本吗？开无痕窗口、换台设备、抓一下响应头里的 cache-control——十有八九是缓存还在替旧版站岗。把缓存管好，「怎么改都改不好」的玄学也就散了。