吃透浏览器原生Fetch API：从基础请求到边界场景的完整攻略

写前端这些年，我见过太多人一提到网络请求就默认去装 axios，问原因只回一句“大家都这么用”。但浏览器自带的那套 Fetch API，其实才是离你最近、也最值得吃透的方案：原生支持 Promise，语法干净，不引第三方库就能覆盖绝大多数接口调用场景。问题在于，Fetch 的官方文档看起来很简单，真正落到项目里却到处是坑：POST 传 JSON 忘了加 Content-Type，服务端直接甩 400；接口明明返回 500，fetch 却不抛任何异常；超时、取消、跨域、上传进度，每个点都能让新手折腾一整天。这篇文章把我这些年实际项目里踩过的 Fetch 坑和沉淀下来的套路一次性捋清楚，给刚入门的朋友一份能直接抄作业的完整攻略，也给用了一段时间、但总在边界场景卡壳的同学查漏补缺。只讲我真正用过、验证过的方案，不绕弯子。

1. 为什么值得吃透Fetch：先从定位和选型说起

1.1 Fetch到底是个什么级别的API

Fetch API 是浏览器提供的原生全局方法，挂在 window 和 Worker 环境上，最早的完整实现可以追溯到 Chrome 42 时代，到今天所有现代浏览器都原生支持，不需要任何 polyfill 或第三方库。它设计的目标很明确：用一套基于 Promise 的简洁接口，替代过去那套以回调事件为主的 XMLHttpRequest。从 Node.js 18 开始，Node 也把 Fetch 作为原生能力引入，也就是说同一个 fetch 写法，前端和后端都能跑，这对做全栈或者写脚本的人来说非常友好。

但实际项目里很多同学对 Fetch 的态度是“用过但没吃透”——会用 response.json()，却不知道 response 只能消费一次；会发 GET，却搞不定 POST 的 Content-Type。原因在于 Fetch 的 API 设计是“基础用法极简，边界情况全靠自己”。理解了它的定位，你就知道哪些坑是设计使然，哪些坑是真踩出来的。

1.2 一张表看清Fetch、XHR、axios的差别