HTTP 缓存机制是什么？包括强缓存和协商缓存。

解释 HTTP 缓存的两种机制：强缓存基于时间检查，协商缓存通过 ETag 或 Last-Modified 验证。

网络协议中等 HTTP 缓存缓存机制

HTTP缓存机制通过在客户端缓存资源副本，减少网络请求和服务器负载，从而提高Web性能。它包括强缓存和协商缓存两类策略，共同决定客户端（如浏览器）如何读取缓存资源而不必频繁与服务器交互。

原理：浏览器直接读取本地缓存而不与服务器交互，适用于资源在有效期内未过期时。
HTTP头部字段：
- Cache-Control（主流方案）：设置缓存策略指令。
  如：
```
Cache-Control: max-age=3600, public
```
  - max-age=<seconds>：资源缓存的相对时间（秒），优先级高。
  - public：资源可被代理服务器缓存。
  - no-cache：需要协商缓存（不与Expires混用）。
  - no-store：禁止任何缓存。
- Expires（过时机制）：指定资源绝对过期时间（例：Expires: Tue, 01 Jan 2030 00:00:00 GMT）。易因时间不同步失效，HTTP/1.0中被Cache-Control取代。
命中条件：客户端首次请求资源时收到响应头字段；后续请求中若未超出有效期：
- 直接使用缓存资源。
- 返回200 (from disk cache) 或 200 (from memory cache)状态码，无需网络请求。

原理：当强缓存失效，浏览器向服务器发送验证请求判断缓存是否仍有效，减少资源传输。
HTTP头部字段：
- Last-Modified（服务器→客户端）：记录资源最后修改时间（例：Last-Modified: Mon, 01 Jul 2024 00:00:00 GMT）。
  If-Modified-Since（客户端→服务器）：附带上次请求时收到的修改时间，询问资源是否变更。
- ETag（服务器→客户端）：设置唯一资源标识符（哈希值）。
  If-None-Match（客户端→服务器）：附带缓存的ETag值，用于验证。
  如请求示例：
```
GET /resource HTTP/1.1
Host: example.com
If-None-Match: "a1b2c3d"
```
交互流程：
1. 客户端发送请求包括验证字段（如If-Modified-Since）。
2. 服务器对比资源状态：
  - 未修改（标识一致）→ 返回304 (Not Modified)，客户端继续使用缓存。
  - 已修改 → 返回200 OK + 新资源，更新本地缓存。

执行顺序：
1. 先检查强缓存（Cache-Control/Expires）。若命中则跳过协商；若失效则进入协商流程。
最佳实践：
- 静态资源（如JavaScript或CSS）：使用max-age=31536000（一年）配合内容哈希文件名（例：app.a1b2c.js），确保版本更新触发缓存刷新。
- 动态资源：设置no-cache强制协商缓存。
注意事项：
- ETag优于Last-Modified，因后者最小时间精度仅1秒。
- Cache-Control指令如no-store会完全跳过缓存机制。