Fetch 的 cache 参数需在 options 中显式设置，决定浏览器如何复用本地缓存，但必须与服务端 Cache-Control 等响应头协同才可靠；常用值包括 default（遵响应头）、no-cache（强制校验）、no-store（禁用读写）、force-cache（优先过期缓存）、only-if-cached（仅缓存，无则失败）。
在 Fetch 请求中配置 cache 策略，关键是在 fetch() 的第二个参数（options）里显式传入 cache 字符串值。它不依赖响应头自动生效，而是直接指导浏览器如何使用本地缓存——但必须与服务器返回的 Cache-Control 等头协同才可靠。
常用 cache 值及适用场景
• default：浏览器按默认逻辑处理，主要看响应头中的 Cache-Control 或 Expires。适合静态资源（如 CSS、图片），但若后端没设缓存头，可能每次重请求。
• no-cache：强制每次向服务器验证缓存有效性（发 If-Modified-Since 或 ETag）。适合内容常更新但又想复用未变资源的场景，比如文章列表页。
• no-store：彻底禁用缓存，不存也不读。适用于敏感操作，如密码修改、支付确认接口，确保数据绝对新鲜且不留痕迹。
立即学习“Java免费学习笔记（深入）”；
• force-cache：优先用缓存，哪怕已过期；仅当缓存完全不存在时才发起网络请求。适合字体、图标等极低变更频率的资源，可显著提速，但需确保部署时同步更新缓存版本。
• only-if-cached：只从缓存取，无缓存就失败（返回 504 或 404）。多用于 PWA 离线策略，配合 Service Worker 实现“有缓存则快，无缓存则拒”。
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
实际写法示例
```js
fetch('/api/user/profile', {
cache: 'no-cache' // 每次校验是否更新
})
.then(res => res.json())
.then(data => console.log(data));
```
注意：cache 必须在 Request 初始化时设置，不能后续修改；也不能在 Response 对象上设置。
容易踩的坑
• 误用 reload：它会跳过所有缓存强制拉新，但也会阻塞页面渲染，频繁使用会让性能反降 300%。
• 忽略服务端配合：前端设了 force-cache，但服务端返回 Cache-Control: no-cache，浏览器仍可能拒绝缓存。
• 在 Service Worker 中 fetch 时不显式调用 caches.put()：即使响应带了 max-age=1000y，也不会进入 Cache API，cache 选项对 Cache API 无效。
进阶建议：搭配 Service Worker 控制“永不过期”
真正可控的长期缓存要靠 Service Worker 主动管理：
• install 阶段用 caches.addAll() 预埋资源；
• fetch 事件中对特定路径（如 /static/）只走 caches.match()，不 fallback 网络；
• 用版本化缓存名（如 v2-static）避免旧缓存残留。
