Fetch API缓存策略核心是cache选项，需与服务器Cache-Control响应头协同生效；6种取值包括default（按响应头自动缓存）、no-store（禁用缓存）、no-cache（强制验证）、reload（忽略缓存重发）、force-cache（强制用缓存）、only-if-cached（仅读缓存）。
Fetch API 中设置请求缓存策略，核心是通过 request 的 cache 选项 控制浏览器如何使用本地缓存，但它不能替代服务器的 Cache-Control 响应头——两者必须配合才有效。
cache 选项的6种取值及适用场景
该选项在 fetch(url, { cache: 'xxx' }) 中传入，仅影响客户端行为，不改变请求头本身：
-
default：浏览器按响应头（如
Cache-Control或Expires）自动决定是否用缓存。最常用，但前提是后端已正确配置缓存头。 - no-store：完全禁用缓存，每次请求都走网络，不读也不存。适合密码修改、支付确认等敏感操作。
-
no-cache：强制验证缓存有效性（发带
If-None-Match或If-Modified-Since的请求），服务器返回 304 则复用本地副本。适合价格、库存、新闻列表等需“准实时”更新的数据。 - reload：跳过所有缓存，强制发起新请求并忽略已有缓存（但响应仍可能被缓存）。慎用——它会增加服务器压力，且不保证数据最新（因没走验证流程）。
-
force-cache：即使响应头声明不可缓存（如
Cache-Control: no-cache），也强制使用本地缓存副本。仅适用于你完全信任缓存内容、且能接受短暂过期的场景（如离线兜底）。 -
only-if-cached：只从缓存读取，不发起网络请求。若缓存不存在，直接报错（
TypeError: Returned response is null）。常配合 Service Worker 使用，实现纯离线访问。
必须同步配置服务端 Cache-Control 响应头
前端设了 cache: 'no-cache'，但后端没返回 ETag 或 Last-Modified，浏览器就无法验证，实际退化为普通请求。所以后端至少要提供以下之一：
-
Cache-Control: public, max-age=3600（强缓存 1 小时） -
Cache-Control: no-cache+ETag: "abc123"（启用协商缓存） -
Cache-Control: private, max-age=60（用户私有缓存，60 秒有效）
Node.js 示例：
立即学习“Java免费学习笔记（深入）”；
res.setHeader('Cache-Control', 'public, max-age=1800');<br>res.setHeader('ETag', crypto.createHash('md5').update(JSON.stringify(data)).digest('hex'));
怎么验证缓存是否生效？
打开 Chrome DevTools → Network 面板，观察请求的 Size 列：
-
from memory cache或from disk cache：强缓存命中 -
304 Not Modified：协商缓存命中 - 完整响应体（如
200 OK）+ 正常大小：未命中缓存或被绕过
注意：勾选 “Disable cache” 会强制禁用所有缓存，调试时记得取消勾选。
