一、浏览器缓存机制详解
浏览器缓存主要分为两类：强缓存和协商缓存。它们像两道关卡，决定了资源是从本地加载还是从服务器获取。
1. 强缓存（无需询问服务器）
强缓存是指浏览器在缓存有效期内，直接使用本地副本，不发送任何请求。它由以下两个 HTTP 响应头控制：
- Expires：HTTP/1.0 的产物，指定一个绝对的过期时间（如
Expires: Wed, 21 Oct 2025 07:28:00 GMT）。缺点是依赖客户端时间，容易出问题。 - Cache-Control：HTTP/1.1 的规范，优先级高于 Expires。常用指令有：
max-age=3600：资源在 3600 秒内有效。public：允许所有中间节点（如 CDN）缓存。private：只允许浏览器缓存。no-cache：不直接使用强缓存，但允许协商缓存（后面解释）。no-store：完全禁用缓存，每次都请求服务器。
当强缓存命中时，浏览器直接从磁盘或内存中读取资源，Network 面板显示 200 (from disk cache) 或 200 (from memory cache)。
2. 协商缓存（需要询问服务器）
当强缓存过期（或设置了 no-cache）时，浏览器会携带缓存的标识向服务器发起请求，由服务器判断资源是否更新。如果未更新，返回 304 状态码，告诉浏览器继续使用缓存；如果已更新，返回 200 和新资源。
协商缓存也由两组响应头/请求头控制：
- Last-Modified / If-Modified-Since：
- 服务器返回
Last-Modified: 文件最后修改时间。 - 下次请求时，浏览器带上
If-Modified-Since: 上次返回的时间。 - 服务器对比时间，如果文件未修改则返回 304。
- 缺点：时间精度只到秒，如果文件在 1 秒内多次修改，可能无法识别；且时间可能因代理服务器修改而失真。
- 服务器返回
- ETag / If-None-Match：
- 服务器根据文件内容生成唯一标识（如哈希值），返回
ETag: "xxxx"。 - 下次请求时，浏览器带上
If-None-Match: "xxxx"。 - 服务器对比 ETag，如果一致则返回 304。
- ETag 解决了 Last-Modified 的精度问题，但计算 ETag 会消耗服务器性能。
- 服务器根据文件内容生成唯一标识（如哈希值），返回
二、前端代码更新的缓存难题
我们的前端资源通常包括：HTML、JS、CSS、图片等。它们有不同的缓存策略需求：
- HTML：希望每次请求都获取最新版本，因为 HTML 里引用了其他资源的链接（如
<script src="app.js">）。 - JS/CSS/图片：希望长期缓存，提升性能，但当内容变化时，浏览器能加载新版本。
如果所有资源都设置长期缓存，那么代码更新后，用户访问页面时，HTML 可能还是旧的，引用的也是旧的 JS/CSS，导致新功能无法生效。这就是典型的'缓存更新问题'。
三、终极解决方案：基于文件内容的哈希命名
核心思想：让资源 URL 随内容变化而变化。这样，即使资源被长期缓存，当内容变化时，URL 也会变化，浏览器自然就会请求新资源。
1. 给静态文件加上哈希值
使用构建工具（Webpack、Vite 等）在文件名中注入内容哈希：
output: {
filename: '[name].[contenthash:8].js',
chunkFilename: '[name].[contenthash:8].chunk.js'
},
plugins: [
new MiniCssExtractPlugin({
filename: '[name].[contenthash:8].css'
})
]
这样生成的文件名类似于 main.3a2b5f7e.js、main.8c3d9e.css。文件内容变化，哈希值就变化，URL 也就变了。
2. HTML 文件：不缓存或短缓存
HTML 文件应该设置较短的缓存时间，或者直接禁用缓存，确保每次请求都拿到最新的资源引用。
通过服务器配置（以 Nginx 为例）：
location / { # 对 HTML 文件设置 no-cache，强制每次验证
if ($request_uri ~* \.html$) {
add_header Cache-Control "no-cache, must-revalidate";
}
# 对 JS/CSS 等静态资源设置长期缓存
if ($request_uri ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff2?|ttf|eot)$) {
expires 1y;
add_header Cache-Control "public, immutable";
}
}
或者在 HTML 的 meta 标签中设置（不推荐，因代理服务器可能忽略）：
<meta http-equiv="Cache-Control" content="no-cache">
3. CDN 缓存控制
如果使用了 CDN，需要协调 CDN 缓存策略。一般原则：
- 对带哈希的文件，设置超长缓存（如 1 年），CDN 和浏览器都会缓存。
- 对 HTML 文件，设置
Cache-Control: no-cache或较短的max-age，并开启 CDN 的'回源验证'功能，确保每次请求都回源检查。
4. 处理旧版本资源
带哈希的文件长期缓存后，旧版本的文件不会被删除，会一直占据 CDN 和服务器空间。解决方案：
- 在构建时清理旧文件（如使用
clean-webpack-plugin）。 - 设置 CDN 自动清理过期缓存，或使用版本号目录（如
/v1/,/v2/）来管理。
四、其他辅助策略
1. 使用 immutable 指令
对于带哈希的文件，可以在 Cache-Control 中添加 immutable 指令，告诉浏览器'这个文件永远不会变'，可以放心缓存。浏览器收到 immutable 后，甚至不会发送条件请求，直接使用缓存。这能进一步提升性能。
Cache-Control: max-age=31536000, immutable
2. 服务端配置 ETag 和 Last-Modified
对于 HTML 等需要验证的资源，保留 ETag 和 Last-Modified，让协商缓存起作用。
3. 动态资源（如 API）的缓存控制
API 接口通常不应被浏览器缓存，或者根据业务需求设置合适的缓存策略。建议设置：
Cache-Control: no-cache, no-store, must-revalidate
五、实战案例：从混乱到清晰
改造前
- 文件：
app.js，style.css，index.html - 服务器设置：所有资源缓存 1 年
- 问题：更新
app.js后，用户仍然请求旧app.js，功能失效。
改造后
- 构建配置：输出文件为
app.abc123.js，style.def456.css。 - 服务器配置：
- 对
.js|.css等设置max-age=31536000, immutable。 - 对
index.html设置no-cache并启用 ETag。
- 对
- 发布流程：
- 每次发布生成新的哈希文件。
index.html自动更新引用为新的哈希文件。
- 用户访问：
- 第一次访问：获取最新 HTML 和资源。
- 后续访问：HTML 始终回源验证（返回 304 或 200），资源直接使用本地缓存。
- 发布新版本：HTML 更新，引用的资源 URL 变化，浏览器请求新资源。
六、可能遇到的坑及解决方案
1. 代理服务器缓存
有些代理服务器（如企业网关）可能会无视 Cache-Control 强制缓存。解决方案：在 URL 中加入版本号或时间戳，但会破坏长期缓存的优势。折衷方案：使用 private 指令，只允许浏览器缓存，不允许中间代理缓存。
2. 哈希计算的不稳定性
Webpack 的 [contenthash] 在不同构建间可能因为模块顺序变化而变化，即使内容没变。解决方案：使用 optimization.moduleIds: 'deterministic' 和 optimization.chunkIds: 'deterministic' 确保模块 ID 稳定。
3. 多页面应用
每个 HTML 都需要独立配置缓存策略，并且要确保引用的资源路径正确。可以使用 HtmlWebpackPlugin 自动注入带哈希的资源。
4. 图片等媒体文件的缓存
图片通常不常变化，也可以使用哈希命名，设置长期缓存。如果图片需要替换，但希望保持相同 URL（如用户头像），则不能使用哈希，而应设置合适的缓存时间并配合版本号参数。
七、总结：缓存策略黄金法则
- HTML 文件：
Cache-Control: no-cache，配合 ETag 协商缓存。 - 带哈希的静态资源：
Cache-Control: max-age=31536000, immutable，永久缓存。 - API 接口：根据业务需求，通常
no-cache或短时缓存。 - CDN：遵循上游策略，对带哈希资源设置长时间缓存，HTML 文件设置回源验证。
- 构建工具：利用
contenthash确保 URL 随内容变化。
遵循这套策略，你就能彻底解决前端代码更新后的缓存问题，既保证了性能，又实现了无缝更新。