浏览器强缓存还未过期，但服务器资源已经变了怎么办？

在前端开发中，我们常通过浏览器的缓存机制来提升页面加载速度和用户体验。尤其是强缓存（Strong Cache），能让浏览器在下次访问资源时完全不发出网络请求，直接使用本地缓存，大幅节省请求时间。

但强缓存也带来一个经典问题：

如果浏览器缓存的资源还在有效期内（比如 max-age=1d），但服务器上的文件已经被更新了，用户仍然会使用过期的老资源。该怎么办？

本文将深入剖析这个问题，并提供可靠的解决方案。

浏览器的强缓存主要通过以下两个响应头控制：

当浏览器加载一个资源，如果在有效期内再次访问同一个 URL，会直接使用本地缓存，不发请求，也不会校验服务器资源是否有变化。

例如：

用户首次加载网页，服务器返回 /main.js，并带上响应头：
```
Cache-Control: max-age=86400
```
浏览器缓存该资源，有效期为 24 小时。
第二天服务器更新了 /main.js 的内容（如修复了 bug 或发布了新功能）。
但用户浏览器中仍在缓存有效期内，不会再次请求服务器，而是使用旧版文件。

结果就是：用户访问的是旧代码，看不到更新内容，甚至可能报错。

强缓存的机制本质上就是信任服务器对“资源多久会过期”的声明。一旦浏览器收到一个 max-age=86400 的响应，它就会认定这个资源在 24 小时内都有效，不再验证服务器是否更新了内容。

这就意味着：

这是目前前端界的最佳实践。

将静态资源文件名加入内容 hash 值。例如：

每次构建后，只要内容有变化，hash 就会变化，文件名也随之改变。这样浏览器即使之前缓存了 main.3a4c9d1.js，下次请求的是 main.8fd3ab2.js，就会重新发起请求，获取更新后的资源。

构建工具如 Webpack、Vite 都默认支持这种 hash 文件命名方式。

如果不能使用 hash 文件名，也可以通过设置较短的 max-age（如 300 秒），同时启用协商缓存机制：

设置响应头：

Cache-Control: max-age=300
ETag: "abc123"

前端代码请求资源时可手动拼接版本参数，例如：

/main.js?v=1.0.2

只要版本变更，URL 也变了，浏览器就会重新请求。

适用于某些动态加载资源（如图片、接口数据等），但不是主流做法。

资源类型	推荐缓存策略
JS / CSS / 图片	文件名加 hash + 强缓存一年（`Cache-Control: max-age=31536000, immutable`）
HTML 页面	不强缓存，使用协商缓存（`Cache-Control: no-cache` + `ETag`）
接口返回数据	结合 `ETag` / `Last-Modified` 做协商缓存
动态图片、上传内容	使用版本号或时间戳清缓存