夜里改完样式却不生效，缓存工具该按什么顺序挑

晚上十一点半，夜里样式页面样式刚改完，改完工具该按测试同事在群里说“还是生效什顺旧的”。你刷新、缓存强刷、序挑换浏览器，夜里样式依旧不对。改完工具该按再过二十分钟发布窗口就关了，生效什顺这时候最忌讳的缓存是打开应用商店，把带“缓存清理”“网页加速”字样的序挑工具挨个装一遍。工具越多，夜里样式变量越多，改完工具该按最后连问题出在哪一层都说不清。生效什顺更稳的缓存做法是按顺序排除，每走一步都留下判断依据，序挑失败了再换下一条路。

先确认是不是浏览器端在拦：强刷与无痕窗口

第一步永远不是装工具，而是用浏览器自带的手段做一次对照。普通刷新会带上缓存策略重新请求，强制刷新（Windows 上一般是 Ctrl+F5，macOS 上常用 Cmd+Shift+R）会绕过本地缓存去要新文件。如果强刷之后对了，说明问题在浏览器本地缓存或中间层缓存，不在代码本身。

接着开一个无痕窗口，或换一个没登录过该站点的浏览器配置，再访问同一地址。无痕窗口基本不带旧的本地缓存，如果这里显示正常，而正常窗口不正常，基本可以锁定是本地缓存或扩展在作怪。此时先临时停用广告拦截、脚本管理一类扩展，再刷新一次。很多“改了不生效”其实是扩展注入了旧版本资源，跟缓存工具本身没关系。

这一步的失败信号也很明确：无痕窗口里依旧是旧内容。那就别再折腾本地清理了，往下走。

再看响应头与资源版本号，判断缓存发生在哪一层

打开开发者工具的“网络”面板，勾选禁用缓存，刷新页面，点开那个没更新的 JS 或 CSS 文件，看响应头里的 Cache-Control、ETag、Last-Modified。如果 Cache-Control 给了很长的 max-age，而文件名里又没有带哈希，那浏览器按规则缓存旧文件是正常行为，不是 bug。解决办法是改文件名或加版本参数，而不是反复清缓存。

如果响应头显示 no-cache 或很短的最大缓存时间，但拿到的内容仍是旧的，问题就可能出在中间的 CDN 或反向代理。这时浏览器缓存相关工具帮不上忙，你需要找运维确认刷新节点的操作。判断依据是：同一文件在不同网络、不同地区请求，返回的内容或头部不一致。

还有一种常被忽略的情况：页面引用的地址没变，但服务端返回的是旧构建产物。这时清一百次本地缓存都没用，因为源头就是旧的。看构建时间戳、比对文件哈希，比装任何清理工具都直接。

确实要选清理工具时，看它动的是哪一层

走到这一步，才轮到考虑浏览器缓存相关工具。选之前先问自己：我要清的是当前站点，还是整个浏览器；是清 HTTP 缓存，还是连带 Cookie、本地存储、Service Worker。多数浏览器自带的“清除浏览数据”已经够用，能按时间范围和类型勾选，优先用它，因为行为可预期、可回溯。

需要装第三方工具的情形其实很窄：比如要批量比对多个站点的缓存头，或者开发调试时频繁切换缓存状态。这时看三个点。第一，它是否明确说明清理范围，能不能只针对某个域名。第二，它是否要求读取所有网站的浏览数据，权限越大越要谨慎。第三，它是否有可核对的更新记录和来源说明，而不是只有一句“一键加速”。

不建议用那种宣称能“深度优化”“释放内存”的清理软件去处理开发问题。它们往往顺手清掉登录态和本地存储，导致你排了半天缓存，结果把调试环境弄丢了。清之前把当前站点的 Cookie 和 localStorage 里需要的东西记一下，或者先用导出功能留个底。

清完仍不对，就换到服务端与网络这一路

如果本地清了、无痕也试了、响应头也看了，内容还是旧的，别再换第三个清理工具，直接换方向。用命令行请求同一地址，看返回内容是否和浏览器一致；用手机流量访问，排除公司网络代理的影响；让同事在他机器上打开，确认是不是只有你这边异常。

这几步能把范围压到很小：只有你异常，查本机代理、hosts、扩展；多人都异常，查 CDN 与发布流程；命令行正常而浏览器不正常，回到浏览器配置和扩展。每一步都有明确的下一步，不需要靠猜。

时间紧的时候，记住一个原则：先做能撤销的操作，再做不可撤销的。强刷、无痕、临时停用扩展都可逆；卸载重装、批量清理所有站点数据、改系统代理，事后很难还原。夜里排查问题，稳比快更重要，因为返工一次就是半小时。

回到那个十一点半的场景：强刷先看，无痕再验，网络面板确认头部和版本号，最后才考虑工具，且优先用浏览器自带的。工具是排查到某一层之后的辅助，不是起点。顺序对了，多数“缓存不生效”在第二步就能定位，剩下的交给对应那层的人处理。