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

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

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

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

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

一、强缓存回顾

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

• Cache-Control: max-age=xxx：表示资源在 xxx 秒内有效，无需重新请求
• Expires: 日期字符串：资源过期时间（HTTP 1.0，已较少使用）

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

二、问题出现的场景

例如：

1. 用户首次加载网页，服务器返回 /main.js，并带上响应头：

   Cache-Control: max-age=86400
   

   浏览器缓存该资源，有效期为 24 小时。

2. 第二天服务器更新了 /main.js 的内容（如修复了 bug 或发布了新功能）。

3. 但用户浏览器中仍在缓存有效期内，不会再次请求服务器，而是使用旧版文件。

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

三、为什么会这样？

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

这就意味着：

• 内容有没有变化，浏览器不知道
• 只要时间没过期，就不会重新请求

四、如何解决这个问题？

方法一：使用文件名加 hash（推荐）

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

实现方式：

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

• 原文件名：main.js
• 构建后变为：main.3a4c9d1.js

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

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

优点：

• 完全避免“缓存未过期但内容已变”的问题
• 浏览器可以无限期缓存资源（max-age=31536000），提升性能

方法二：缩短缓存时间 + 启用协商缓存

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

• 设置响应头：

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

• 浏览器在 5 分钟内使用缓存，5 分钟后再次请求时会带上：

  If-None-Match: "abc123"
  

• 服务器判断资源是否变更：

  • 没变 → 返回 304 Not Modified，不传输内容
  • 有变 → 返回 200 OK + 新内容

优点：

• 缓存有效但仍可检测资源变化
• 保证一定程度的实时性

缺点：

• 每隔一段时间仍需发请求，占用带宽
• 配置较复杂，依赖后端协助

方法三：每次发请求时带上版本号参数

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

/main.js?v=1.0.2

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

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

五、不同资源的缓存策略推荐

六、总结

浏览器强缓存在性能优化中起着非常重要的作用，但也可能因内容更新而无法及时刷新，导致用户访问到旧资源。

避免这个问题的根本方法是：

• 为资源添加唯一的版本标识（如文件名 hash）
• 控制不同资源的缓存策略，结合强缓存和协商缓存使用