前端缓存深度解析：从强缓存机制到 Webpack 长期缓存实践
前言
在现代前端开发中，缓存是性能优化的第一手段。一个配置精良的缓存策略，可以使页面的二次加载时间从秒级降至毫秒级。然而，缓存也是一把双刃剑：如果配置过激，会导致用户无法获取最新的业务代码；如果配置过松，则会造成带宽资源的巨大浪费。本文将拆解 HTTP 缓存的内部原理，并探讨 Webpack 如何通过哈希策略完美配合浏览器缓存。
一、 浏览器缓存的分层模型
浏览器在发起任何网络请求前，都会先经过一套复杂的内部过滤机制。
1. 强缓存 (Strong Cache)
这是最有效的缓存手段。浏览器直接检查本地磁盘，如果资源未过期，则直接读取，不与服务器发生任何通信。
- 核心字段：
Cache-Control: max-age=31536000(单位为秒)。 - 表现： 在控制台 Network 面板显示
200 (from disk cache)或200 (from memory cache)。
2. 协商缓存 (Negotiation Cache)
当强缓存失效（过期）后，浏览器会尝试与服务器"协商"。
- 流程： 浏览器发送请求，并在 Header 中携带
If-None-Match（上一次获取的 ETag 指纹）。 - 结果： * 若文件未变动，服务器返回 304 Not Modified，不包含 Body。
- 若文件已变动，服务器返回 200 OK 以及最新的文件内容。
二、 强缓存的"盲区"与 Webpack 的哈希解法
1. 强缓存的物理特性
强缓存具有不可控性 。一旦服务器下发了长达一年的 max-age，只要资源 URL 不变，浏览器绝不会主动去服务器检查更新。这意味着，如果你直接覆盖服务器上的 app.js 但名字没变，用户在缓存到期前永远看不到新功能。
2. Webpack 的哈希指纹（ContentHash）
为了利用强缓存带来的极致性能，同时解决"更新感知"问题，前端工程化引入了文件名哈希机制。
-
原理： Webpack 根据文件内容生成唯一的摘要值（Hash）。
-
逻辑演进： * 修改前：
index.html引用script.a1b2.js -
修改后：文件内容变化，Webpack 生成
script.c3d4.js，同步更新index.html中的引用。 -
结果： 对浏览器而言，
script.c3d4.js是一个从未见过的新 URL，它会跳过旧缓存直接下载新资源。
三、 缓存存储与清理机制
1. 内存缓存 vs 磁盘缓存
| 类型 | 存储位置 | 声明周期 | 读取速度 |
|---|---|---|---|
| Memory Cache | 内存 | 随进程结束（标签页关闭） | 极快 (0ms) |
| Disk Cache | 硬盘 | 随配额或 LRU 算法清理 | 较快 |
2. 磁盘配额与 LRU 算法
用户硬盘不会因为缓存而崩溃。浏览器会严格限制每个域名可占用的存储配额。
- LRU (Least Recently Used)： 当磁盘空间不足时，浏览器会优先清理那些"最久未被访问"的缓存资源，即使它们仍处于
max-age有效期内。
四、 最佳实践配置方案
针对 Webpack 项目，最严谨的缓存策略建议如下：
1. HTML 文件：协商缓存
- 配置：
Cache-Control: no-cache - 原因： HTML 是入口。必须保证每次访问都去服务器校验，以确保获取最新的 JS/CSS 链接。
2. 静态资源（JS/CSS/Image）：强缓存
- 配置：
Cache-Control: public, max-age=31536000 - 前提： 必须在 Webpack 导出文件名中包含
[contenthash]。
3. 注意事项：请求头开销
虽然 HTTP/2 解决了并发问题，但不要走向"过度拆包"的极端。
- 每一个微小的 Chunk 都有其 Header 开销（即便经过 HPACK 压缩）。
- 建议将第三方依赖（Vendor）和业务代码分离，保持适度的文件大小，以平衡缓存命中率与网络传输效率。
五、 总结
缓存优化的本质是在传输成本 与更新实时性之间寻找平衡。
- 通过 HTTP 强缓存 消除不必要的网络请求。
- 通过 Webpack ContentHash 实现精准的缓存失效控制。
- 通过 协商缓存 确保入口文件的绝对可靠。