你有没有遇到过这种情况：开发好的网页，在自己电脑上显示正常，一到同事的浏览器里就出问题？刷新也没用，清掉缓存才恢复正常。这背后很可能就是浏览器缓存的“锅”，更麻烦的是，它还和兼容性搅在一起，让问题变得更复杂。
缓存本无错，但各浏览器理解不同
浏览器缓存是为了提升加载速度，把静态资源比如JS、CSS、图片存下来，下次访问直接用本地的。听起来很美好，但不同浏览器对缓存策略的实现有细微差别。比如Chrome可能严格按照HTTP头里的Cache-Control执行，而某些老版本IE却喜欢“自作主张”地多缓存一会儿。
举个例子：你上线了一个新功能，更新了main.js。用户用Chrome打开，发现功能正常；可另一个用Edge旧版的用户，加载的还是上周的缓存文件，结果按钮点不动，表单提交失败。你查代码查半天，发现根本不是逻辑问题，而是他浏览器压根没加载新脚本。
强缓存与协商缓存的兼容差异
强缓存靠Expires和Cache-Control控制，浏览器不发请求直接用本地副本。但像Safari在隐私模式下会弱化强缓存，而Firefox在某些设置下会忽略max-age。这意味着同一套缓存头，在不同环境表现不一。
协商缓存依赖Last-Modified和ETag。问题来了：有些服务器集群生成的ETag不一致（比如基于inode），导致负载均衡后，用户在A节点拿到的ETag和B节点对不上。这时候即使文件没变，浏览器也会当成新资源重新下载。某些浏览器处理这种冲突更敏感，造成重复加载或样式错乱。
前端部署时的常见翻车现场
很多团队习惯给静态资源加版本号，比如style.css?v=1.2.3。这招在大部分情况下管用，但如果你只改了HTML里的引用，而忘了更新页面内联的JS逻辑判断，某些浏览器可能因为主文档缓存太久，压根看不到新版链接。
更隐蔽的情况是Service Worker。它本身是个缓存代理，一旦注册成功，后续请求都归它管。但如果新版本SW没正确触发更新，或者旧缓存策略没清理干净，用户就会一直卡在旧版页面，哪怕你重启服务器都没用。这时候客服收到的反馈往往是：“别人能用，我就不行”——典型兼容性+缓存双重打击。
怎么减少这类问题
资源文件名加入哈希是最靠谱的办法。Webpack、Vite这些工具默认就把main.js打包成main.abcd1234.js。只要内容变，文件名就变，浏览器自然当作新资源加载。比起参数版本，这种方式彻底绕开缓存歧义。
另外，别忽视HTTP响应头的统一配置。确保Nginx或CDN对静态资源返回一致的Cache-Control，比如：
Cache-Control: public, max-age=31536000, immutable对于HTML文档，则建议设置为：
Cache-Control: no-cache, must-revalidate这样既允许校验缓存，又避免长期滞留。
最后，上线后多用不同设备和浏览器快速验证。别只盯着自己常用的Chrome开发者工具看。有时候安卓微信内置浏览器、iPad上的Safari，才是真正的“试金石”。