fetch请求默认是否使用缓存
在日常开发中，用 fetch 发起网络请求已经成了家常便饭。但你有没有遇到过页面刷新后数据还是旧的？或者明明接口返回变了，前端却没反应？这很可能和 fetch 的缓存机制有关。
fetch 默认会走浏览器缓存吗？
答案是：有可能。fetch 请求本身不会主动绕开缓存，它遵循的是 HTTP 缓存规则，和传统的 XMLHttpRequest（也就是 AJAX）一样，受浏览器缓存策略控制。也就是说，如果服务器返回了缓存头（比如 Cache-Control 或 Expires），浏览器就可能直接从缓存里拿数据，而不去请求服务器。
举个例子：你在做一个天气应用，每次打开页面都用 fetch 获取当前城市天气。如果你之前访问过，并且服务器告诉浏览器“这个数据5分钟内有效”，那接下来的几次请求，浏览器很可能直接返回缓存结果，根本不会发出去真正的网络请求。
如何确认是不是缓存的问题？
打开浏览器开发者工具，看 Network 面板。如果某个 fetch 请求的状态码显示的是 200 (from cache) 或 304 Not Modified，那就说明走了缓存。
想要禁用缓存怎么办？
有几种方式可以控制 fetch 的缓存行为。最直接的是通过 cache 选项：
fetch('/api/data', {\n method: 'GET',\n cache: 'no-cache' // 每次都重新验证缓存\n})其他常用选项还有：
cache: 'no-store'：完全不使用缓存，每次都从服务器拉取cache: 'force-cache'：强制使用缓存，即使已过期cache: 'reload'：忽略缓存，但会把响应存入缓存
如果你不想改代码逻辑，也可以在请求 URL 后加个时间戳参数来绕过缓存：
fetch(`/api/data?t=${Date.now()}`)这种方式虽然简单粗暴，但在调试阶段挺实用。
服务器也能控制缓存
除了前端控制，后端设置合适的缓存头也很关键。比如希望数据实时更新，服务器可以返回：
Cache-Control: no-cache, no-store, must-revalidate这样浏览器就不会缓存响应，fetch 每次都会发起真实请求。
实际项目中，缓存是个双刃剑。用好了提升性能，用不好就让人摸不着头脑。理解 fetch 的默认行为，能帮你少踩不少坑。