协商缓存和强缓存是 HTTP 缓存机制的两种主要策略，它们的核心区别在于是否向服务器发送请求 以及如何处理缓存更新。
✅ 强缓存（Strong Cache）
核心特点：
- 不发送请求：浏览器直接从本地缓存（disk 或 memory）读取资源。
- 状态码：
200 (from disk cache)或200 (from memory cache) - 控制字段：
Cache-Control: max-age=秒数（推荐）Expires: 绝对时间（已不推荐使用）
- 适用场景： 不常变动的静态资源，如带指纹的 JS、CSS、图片等。
优点：
- 最快速度，无网络开销。
- 减少服务器压力。
缺点：
- 更新不及时，用户可能在缓存有效期内看不到新版本。
✅ 协商缓存（Conditional Cache）
核心特点：
- 发送请求 ，但不传输完整资源，而是向服务器验证资源是否更新。
- 状态码：
304 Not Modified→ 使用缓存200 OK→ 返回新资源
- 控制字段：
ETag/If-None-Match（推荐）Last-Modified/If-Modified-Since（次选）
- 适用场景： 可能频繁更新的内容，如 HTML 页面、API 响应等。
优点：
- 保证资源更新及时性。
- 节省带宽，仅传输头部信息。
缺点：
- 有网络请求延迟，性能略低于强缓存。
✅ 缓存使用顺序（浏览器行为）
- 首先检查强缓存 是否命中（
Cache-Control或Expires）。 - 若强缓存未命中，则进入协商缓存流程，发送请求并带上验证字段。
- 服务器根据验证字段决定返回
304还是新资源。
✅ 实际应用建议
| 类型 | 推荐配置示例 | 使用场景 |
|---|---|---|
| 强缓存 | Cache-Control: max-age=31536000, immutable |
带哈希的 JS/CSS/图片 |
| 协商缓存 | Cache-Control: no-cache + ETag |
HTML、API 接口、动态内容 |
✅ 用户操作对缓存的影响
| 操作方式 | 强缓存是否生效 | 协商缓存是否触发 |
|---|---|---|
| 正常跳转/链接点击 | ✅ 生效 | ❌ 不触发 |
| 刷新（F5） | ❌ 不生效 | ✅ 触发 |
| 强制刷新（Ctrl+F5） | ❌ 不生效 | ❌ 不生效 |
✅ 总结一句话
强缓存 是"能用就别问"，协商缓存是"过期了先问一句还能不能用"。
两者结合使用，能在性能和实时性之间取得最佳平衡。