静态资源文件在浏览器中的缓存机制-优快云博客

本文链接：https://blog.youkuaiyun.com/Yana1225/article/details/146416321

提要：为什么项目部署上线后，静态文件（vue项目中，放在public中的文件，如common.js）在自己的电脑中没有更新，在其他人的电脑中更新了。考虑到了缓存，在html中添加了no-cache等，检查了network中的response headers中没有设置cache-control，那文件的缓存怎么计算？

一、为什么你的电脑有缓存，而其他人没有？

浏览器历史缓存差异
你的电脑可能之前访问过该页面，浏览器已缓存了 common.js（即使 HTML 设置了 no-cache，旧缓存可能依然存在）。而新用户首次访问时无历史缓存，会直接请求最新文件。
本地缓存未清除
浏览器可能未完全清除缓存（如普通刷新 vs 强制刷新），建议使用 Ctrl + F5（Windows）或 Cmd + Shift + R（Mac） 强制跳过缓存。
服务器响应头覆盖 Meta 标签
关键问题可能在于：HTML 中的 <meta> 标签仅控制 HTML 自身的缓存，而静态资源（如 common.js）的缓存由服务器返回的 HTTP 响应头（如 Cache-Control）决定。若服务器对 JS 文件配置了缓存策略，浏览器会优先遵循它。

二、为什么 `<meta>` 标签对 JS/CSS 无效？

<meta http-equiv> 仅作用于 当前 HTML 文件，无法控制其他静态资源（JS/CSS/图片）的缓存行为。

静态资源的缓存策略完全由 服务器的 HTTP 响应头 决定。例如：

# 服务器返回的 JS 文件响应头示例（可能覆盖你的期望）
Cache-Control: public, max-age=31536000

三、Chrome 的缓存机制

缓存时长由什么决定？
- 主要取决于服务器返回的 Cache-Control 或 Expires 响应头。
- 若服务器未明确设置，浏览器会使用 启发式缓存（根据 Last-Modified 时间等推算缓存时间，通常不建议依赖此行为）。

缓存优先级
浏览器按以下顺序决定缓存策略：

# 服务器返回的 JS 文件响应头示例（可能覆盖你的期望）
Cache-Control: public, max-age=31536000

四、解决方案

检查服务器对静态资源的响应头
使用浏览器开发者工具（Network 标签）查看 common.js 的响应头，确认是否包含类似以下配置：
```
Cache-Control: no-cache, no-store, must-revalidate
```
如果服务器返回了 max-age 或其他缓存指令，需修改服务器配置。
强制静态资源更新
在 JS/CSS 文件 URL 中添加版本号或哈希值（如 common.js?v=1.0.1），确保更新后 URL 变化，强制浏览器重新请求。

服务器配置示例
以 Nginx 为例，禁用静态资源缓存：

location /static {
  add_header Cache-Control "no-cache, no-store, must-revalidate";
  add_header Pragma "no-cache";
  add_header Expires 0;
}

用户本地缓存问题
建议用户手动清除缓存，或通过代码控制（如 Service Worker 主动清理旧缓存）。

五、以示例响应头进行分析

HTTP/1.1 200 OK
Server: nginx
Date: Fri, 21 Mar 2025 02:52:52 GMT
Content-Type: application/javascript; charset=utf-8
Last-Modified: Fri, 21 Mar 2025 02:41:06 GMT  # 关键字段
Transfer-Encoding: chunked
Connection: keep-alive
ETag: W/"67dcd1c2-3c04"                        # 关键字段
Content-Encoding: gzip

缺失的缓存控制字段
响应头中未包含 Cache-Control 或 Expires，因此浏览器无法直接确定缓存策略。
启发式缓存触发条件
根据 HTTP 规范，如果服务器未明确指定缓存行为，但提供了 Last-Modified 或 ETag，浏览器会自动启用启发式缓存，通过以下公式计算缓存时间：

六、缓存时间计算公式

浏览器会基于以下规则估算缓存有效期：

缓存时间 = max(0, (Date - Last-Modified) * 0.1)

代入你的数据：

Date: Fri, 21 Mar 2025 02:52:52 GMT（响应生成时间）
Last-Modified: Fri, 21 Mar 2025 02:41:06 GMT（文件最后修改时间）

时间差计算：

02:52:52 - 02:41:06 = 11 分钟 46 秒 = 706 秒

缓存时间：

706 秒 * 0.1 ≈ 70 秒

因此，浏览器可能会将此文件缓存 约 70 秒。

七、潜在风险与问题

缓存时间不可控
不同浏览器对启发式缓存的实现可能不同（例如 Chrome、Firefox 的系数可能调整），实际缓存时间可能有差异。
更新后可能无法立即生效
如果你更新了 common.js 但未修改文件名或版本号，用户可能在缓存时间内看到旧文件。
缓存逻辑不透明
开发者很难依赖这种隐式行为，建议显式控制缓存策略。

八、解决方案

1. 显式设置 `Cache-Control` 响应头

在 Nginx 中为静态资源添加缓存控制，例如：

location ~* \.(js|css)$ {
  add_header Cache-Control "no-cache, max-age=0";  # 强制每次验证
  # 或明确指定缓存时间（如 1 天）：
  # add_header Cache-Control "public, max-age=86400";
}

2. 添加文件版本号（推荐）

在文件名中嵌入哈希值，确保更新后 URL 变化，例如：

<script src="common.js?v=1.0.1"></script>

或使用构建工具自动生成哈希（如 common.a1b2c3.js）。
【不过此方法并不适合我，这个文件在其他项目中也使用了，不适合一次次改。】

3. 验证 `ETag` 和 `Last-Modified`

即使设置 Cache-Control: no-cache，浏览器仍会发送 If-None-Match（基于 ETag）或 If-Modified-Since（基于 Last-Modified）请求，服务器可返回 304 Not Modified 节省带宽。