选 fetch 还是 axios 取决于项目所需抽象层级：fetch 是裸金属接口，需手动处理序列化、解析、错误等；axios 提供语义封装，内置超时、拦截器、跨平台支持等能力。
选 fetch 还是 axios，关键不在“哪个更好”，而在于项目需要什么抽象层级——fetch 是浏览器给你的裸金属接口，axios 是别人帮你焊好散热器、装好仪表盘的整车。
看底层职责是否要自己扛
fetch 就是标准协议的直译器：发请求、收响应、返回 Response 对象。它不关心你传的是对象还是字符串，也不管状态码是 200 还是 500，更不会帮你把 JSON 自动转成 JS 对象。所有解析、校验、序列化都得你写代码补全。
- 发 POST 要手动
JSON.stringify()+ 设置Content-Type - 读响应必须显式调用
res.json()或res.text()，且它是 Promise，得再套一层.then() - 404/500 不进
catch，得靠if (!res.ok) throw …手动拦截 - 超时、上传进度、CSRF 头、cookie 携带……全无默认行为，全靠自己拼接 AbortController、监听 stream、读写 document.cookie
看团队是否愿意维护统一请求层
axios 把常见场景的“胶水逻辑”全打包好了：自动序列化 data、自动解析 response.data、内置 timeout、onUploadProgress、xsrfCookieName、withCredentials 默认策略等。它不是替代 fetch，而是站在 fetch/XHR 之上做了语义封装。
- 错误统一走
catch，err.response?.status直接可用 - 拦截器可集中处理 token 注入、loading 状态、错误弹窗，不用每个
fetch都重复写 - Node.js 和浏览器共用同一套调用方式，SSR 或同构项目省去环境判断
- IE11 兼容性开箱即用，fetch 则需引入 whatwg-fetch polyfill
看交付约束是否倾向零依赖或轻量可控
如果项目是嵌入式控制台、微前端子应用、或对包体积极度敏感（如 PWA 首屏资源），fetch 的“零安装、零体积”就是硬优势。你只要现代浏览器，就能用最简路径完成基础通信。
- 没有 npm install、没有 tree-shaking 风险、没有版本升级带来的 breaking change
- 所有行为透明可见，调试时直接看到原生 Request/Response 实例，不被封装层遮蔽
- 适合封装成极简内部 SDK，比如只暴露
api.get()和api.post()，底层仍用 fetch 但屏蔽了 .json() 嵌套
看长期演进是否需要生态扩展能力
axios 生态成熟：有 axios-retry、axios-cache-adapter、axios-mock-adapter 等官方认可插件；配合 Vue/React 的请求 hooks（如 @tanstack/query）也默认适配 axios 实例。而 fetch 想加重试、缓存、mock，就得自己造轮子或集成第三方中间件（如 ky、undici）。
- 已有大型项目接入 Sentry、Datadog？axios 的拦截器能无缝注入 traceId、记录耗时与状态码分布
- 要做离线优先？axios + cache adapter 比手写 fetch + Cache API + IndexedDB 组合更省力
- 测试中需 mock 所有请求？
jest.mock('axios')比 patchwindow.fetch更稳定可靠
