fetch api中cache选项优先级高于cache-control请求头，六种取值分别控制缓存行为：default（遵循http规则）、no-store（完全绕过）、reload（强制网络并更新缓存）、no-cache（条件验证）、force-cache（强制用缓存）、only-if-cached（仅缓存且需credentials: 'omit'）。
Fetch API 中控制缓存主要靠 cache 选项和请求头 Cache-Control，两者协同工作但优先级不同：Fetch 的 cache 选项会覆盖请求头中的 Cache-Control，浏览器最终按 cache 值执行缓存行为。
Fetch 的 cache 选项决定缓存行为
这是最直接、推荐的方式。在 fetch() 的第二个参数（init）中设置 cache 字段，取值如下：
-
'default'：遵循 HTTP 缓存规则（检查响应头Cache-Control和Expires），默认行为 -
'no-store'：完全绕过缓存，每次发新请求，不读也不写缓存 -
'reload'：强制发起网络请求，忽略已有缓存，但会把响应存入缓存 -
'no-cache'：先查缓存，但每次都会向服务器验证（带ETag或Last-Modified），若未变更则返回 304，否则返回新内容 -
'force-cache'：只读缓存，即使缓存已过期也返回（跳过验证），仅当缓存不存在时才发网络请求 -
'only-if-cached'：只从缓存读取，无缓存则失败（需配合credentials: 'omit'，否则报错）
Cache-Control 请求头仍可配合使用
虽然 cache 选项优先级更高，但设置 headers 中的 Cache-Control 并非无效——它会影响服务端行为（比如 CDN 或代理是否缓存该请求），也作为语义提示保留：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 例如
Cache-Control: max-age=3600告诉中间节点最多缓存 1 小时 - 搭配
cache: 'default'时，浏览器会真正按此头解析缓存时效 - 若同时设了
cache: 'no-store'，则请求头里的Cache-Control对浏览器缓存无影响，但可能被服务器或网关识别
注意 credentials 与 only-if-cached 的限制
cache: 'only-if-cached' 是个特殊模式，它要求请求不能发送凭据（如 cookies、HTTP 认证），否则会抛出 TypeError：
- 必须显式设置
credentials: 'omit' - 不能用
'include'或'same-origin' - 常见于离线场景兜底：先尝试只读缓存，失败再 fallback 到网络
实际组合建议
根据场景选择合理组合：
- 实时数据（如用户余额）→
cache: 'no-cache'或'reload' - 静态资源（JS/CSS）→
cache: 'default'+ 服务端配强缓存（Cache-Control: public, max-age=31536000） - 离线优先应用 → 先用
cache: 'only-if-cached'尝试，捕获异常后重试cache: 'default' - 调试阶段避免缓存干扰 → 直接用
cache: 'no-store'
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
