fetch 的 cache 参数决定是否复用缓存及如何决策，而非简单禁用缓存；其值包括 default（遵http头）、no-store（不读不写）、reload（强制网络请求）、no-cache（先校验）、force-cache（优先用过期缓存）、only-if-cached（仅缓存，无则报错）。
Fetch 默认会遵循 HTTP 缓存规则，但是否真正复用缓存，取决于请求配置、响应头（如 Cache-Control、Expires）以及浏览器的缓存策略。要主动控制缓存行为，关键在 cache 选项和响应头配合。
明确设置 cache 选项控制缓存策略
Fetch 的 cache 配置决定了请求是否查缓存、是否更新缓存、是否跳过缓存。常用值有：
-
default：默认行为，遵循 HTTP 缓存头（如Cache-Control: max-age=3600），可读缓存也可发起条件请求（If-None-Match/If-Modified-Since） -
no-store：完全绕过缓存，既不读也不写，每次发全新请求 -
reload：强制跳过缓存（等价于 Ctrl+F5），但响应仍可能被缓存（除非服务端禁止） -
force-cache：只读缓存，即使缓存过期也返回（忽略max-age），但不会发网络请求 -
only-if-cached：仅当缓存存在且有效时才返回；否则抛出TypeError（常用于离线场景）
服务端响应头决定缓存有效性
客户端设置 cache: 'default' 后，是否复用缓存最终由服务端响应头决定：
-
Cache-Control: public, max-age=600→ 浏览器可缓存 10 分钟，期间重复 fetch 直接返回缓存响应（状态码200 (from memory cache)或(from disk cache)） -
Cache-Control: no-cache→ 每次都需向服务器验证（发送ETag或Last-Modified），若未变则返回304 Not Modified，fetch 会自动解析为原始响应体 -
Cache-Control: no-store→ 浏览器绝不缓存，fetch 每次都走网络
注意：no-cache 不等于“不缓存”，而是“缓存但必须校验”；no-store 才是彻底禁用缓存。
读取缓存响应后正确处理 body
Fetch 响应体（response.body）是一次性流，读取后即耗尽。即使响应来自缓存，也需按常规方式解析：
- 调用
response.json()、response.text()等方法会自动读取并消费流 - 不可多次调用同一响应的
.json()；若需复用，应提前保存解析结果 - 缓存响应的
response.url、response.status、response.headers均正常可用，与网络响应无异
调试缓存是否生效的小技巧
在 DevTools 的 Network 面板中观察请求：
- 查看
Size列：显示from memory cache或from disk cache表示命中缓存 - 检查响应头：确认
Cache-Control、ETag、Last-Modified是否存在且合理 - 对比两次请求的 Timing：缓存命中时
Waiting (TTFB)接近 0ms - 临时加
cache: 'reload'强制刷新，验证服务端是否返回了正确的缓存控制头
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
