Fetch 如何用 cache 参数控制缓存读取

Fetch 的 `cache` 参数并非简单地“开关”缓存，而是精细调控浏览器如何与 HTTP 缓存机制协同工作——它在尊重服务端缓存头（如 `Cache-Control`）的前提下，明确指定每次请求是优先读缓存、强制校验、跳过缓存还是仅限离线可用，从 `default` 的智能默认到 `only-if-cached` 的严格离线保障，每种取值都对应特定的性能、一致性与安全性权衡，掌握其行为差异，才能在真实业务中精准优化加载体验、规避数据陈旧风险，并为离线场景打下可靠基础。

Fetch 的 cache 参数直接决定请求是否复用浏览器已缓存的响应，而不是简单地“禁用缓存”。它不绕过 HTTP 缓存规则，而是告诉浏览器在满足缓存条件的前提下，如何决策：是读缓存、忽略缓存、还是强制校验。

cache 参数的可选值及行为

该参数取值为字符串，常见选项有：

• 'default'：默认行为。遵循 HTTP 缓存头（如 Cache-Control、Expires）。若响应可缓存且未过期，直接返回缓存；否则发起网络请求。
• 'no-store'：完全跳过缓存读写。每次请求都走网络，响应也不存入缓存。适合敏感数据或调试场景。
• 'reload'：强制发起新请求，忽略所有本地缓存（包括 memory cache 和 disk cache），但响应仍可能被缓存（取决于响应头）。
• 'no-cache'：允许读缓存，但必须先向服务器验证（发送带 If-None-Match 或 If-Modified-Since 的条件请求）。服务器返回 304 时复用缓存，200 则更新缓存并返回新内容。
• 'force-cache'：尽可能使用缓存，即使已过期也先返回缓存内容（stale-while-revalidate 类似效果），再异步校验更新。注意：不是所有浏览器都完全支持此行为，尤其在过期严重时可能仍发请求。
• 'only-if-cached'：只从缓存中取，不发起网络请求。若无可用缓存则报错（TypeError: Failed to fetch）。常配合 credentials: 'omit' 使用，避免跨域问题。

与 HTTP 缓存头的协同关系

cache 参数不会覆盖服务器返回的缓存控制头，而是与之配合工作：

• 例如服务端返回 Cache-Control: no-cache，此时即使设置 cache: 'default'，浏览器也会按需校验（等效于 cache: 'no-cache'）。
• 若服务端返回 Cache-Control: immutable, max-age=3600，那么 cache: 'default' 会在 1 小时内直接返回缓存，不校验；而 cache: 'no-cache' 仍会强制校验。
• cache: 'no-store' 是唯一能彻底屏蔽缓存写入的选项，无论响应头怎么写，都不会存。

实际使用建议

根据业务需求选择合适策略：

• 获取静态资源（JS/CSS/图片）：用 cache: 'default'，让浏览器自然遵循服务端缓存策略。
• 用户登录态、支付结果等关键接口：用 cache: 'no-store'，杜绝任何缓存风险。
• 列表页下拉刷新：用 cache: 'no-cache'，兼顾体验（缓存未失效时秒出）和一致性（失效时自动更新）。
• 离线优先应用：可结合 cache: 'only-if-cached' + catch 捕获失败，降级到本地 fallback 数据。

注意点

几个容易踩坑的地方：

• cache 参数对 POST、PUT 等非幂等请求通常无效（浏览器一般不缓存），真正起作用的多是 GET 和 HEAD 请求。
• Service Worker 中拦截 fetch 时，cache 参数会影响 fetch() 在 SW 内部的行为，但最终是否缓存还取决于 SW 自己的逻辑（比如是否调用 cache.put()）。
• DevTools 的 “Disable cache” 开关会覆盖 cache 参数的效果（仅限开发者工具开启时），上线后不生效。

今天关于《Fetch 如何用 cache 参数控制缓存读取》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！