fetch轻量原生但需手动补全功能，axios功能完整开箱即用；小项目优先fetch，中大型项目推荐axios；高阶需求应结合React Query等数据层库。
JavaScript 与后端 API 交互，核心是发起 HTTP 请求并处理响应。目前最常用的是 fetch（原生）和 axios（第三方库），二者没有绝对的“更好”，关键看项目需求和团队习惯。
fetch 更轻量、更现代，但需要手动补全功能
fetch 是浏览器原生支持的 API，无需安装依赖，语法简洁，基于 Promise，天然支持 async/await。但它默认不带 Cookie、不自动处理 JSON 错误状态（比如 404、500 仍算“成功”）、不支持请求/响应拦截、取消请求需靠 AbortController。
常见补足方式：
- 手动添加
credentials: 'include'才能携带 Cookie - 检查
response.ok或response.status判断业务是否失败 - 用
response.json()显式解析 JSON，且需用try/catch捕获解析错误 - 超时控制需自己封装 Promise.race 或用 AbortController
axios 功能更完整，开箱即用，适合中大型项目
axios 是一个成熟的 HTTP 客户端，内置了大量实用特性：自动转换 JSON、默认携带 Cookie（可配）、响应拦截器、请求拦截器、内置超时、取消请求（CancelToken 或 AbortController）、更友好的错误对象（error.response、error.request 等）。
立即学习“Java免费学习笔记（深入）”；
典型优势场景：
- 需要统一添加 token 到请求头 → 用请求拦截器
- 所有接口返回结构统一（如
{ code: 0, data: ..., msg: '' }）→ 用响应拦截器做预处理 - 上传文件要监听进度 → axios 支持
onUploadProgress - 多个请求需批量取消（如搜索联想中途切换关键词）→ 轻松调用
cancel()
小项目或学习阶段，优先用 fetch；业务复杂或团队协作，axios 更省心
如果只是写个静态页面调用公开 API，或者想减少依赖、练手原生能力，fetch 完全够用，也更利于理解底层机制。但一旦涉及登录态管理、错误统一处理、多环境配置、接口监控等，axios 的工程化能力会明显提升开发效率和可维护性。
注意：两者不互斥，可以共存。比如主业务用 axios，某些特殊请求（如流式响应、WebDAV）用 fetch 更灵活。
替代方案也在演进：React Query / SWR 更关注数据层抽象
单纯比 fetch 和 axios，容易忽略更高层的需求——比如缓存、轮询、乐观更新、离线同步。现在主流趋势是配合数据获取库（如 React Query、SWR、Vue Query）使用，它们底层可自由切换 fetch 或 axios，重点解决“如何管理服务端状态”，而非“怎么发请求”。
所以选型逻辑可以是：
→ 先确定是否需要数据缓存和同步能力？需要就上 React Query/SWR；
→ 再看它底层用什么发请求？默认 fetch 就够，需要拦截/适配旧逻辑再换 axios。
