推荐根据项目需求选择：简单现代项目用fetch，中大型或需兼容旧浏览器项目用axios；fetch轻量原生但功能少，axios功能全且易用但需引入依赖。
JavaScript 发起网络请求，fetch 是浏览器原生 API，轻量、标准、无需额外依赖；axios 是第三方库，功能更全、使用更友好、兼容性更好。选哪个，主要看项目需求和团队习惯。
用 fetch 的场景：简单、现代、轻量
fetch 适合不需要复杂配置、目标环境支持较新的浏览器（如 Chrome 42+、Firefox 39+、Edge 14+、Safari 10.1+）的项目。
- 内置 Promise，天然支持 async/await，写法简洁
- 没有默认请求头（比如不自动带 Cookie），需要手动配置
credentials: 'include' - 响应不是直接 JSON，需调用
response.json()才能解析，且fetch不会因 HTTP 状态码报错（404、500 仍算成功），要手动检查response.ok - 不支持请求/响应拦截、取消请求（需 AbortController）、上传进度监听等高级功能
用 axios 的场景：需要稳定、易用、功能完整
axios 更适合中大型项目或需要兼容旧版浏览器（如 IE11）、对错误处理/拦截/取消请求有明确要求的场景。
- 自动序列化请求数据（如对象转 JSON）、自动解析响应 JSON
- 内置请求/响应拦截器，方便统一加 token、loading、错误提示
- 支持取消请求（通过 CancelToken 或 AbortController）、上传下载进度监听
- 默认携带 Cookie（可配置），对 4xx/5xx 状态码自动 reject，错误处理更直观
- Node.js 环境也能用（fetch 需额外 polyfill 或用 node-fetch）
小项目或学习阶段，建议从 fetch 入手
理解原生机制有助于掌握底层逻辑。可以封装一层简单的工具函数，补足常见短板：
立即学习“Java免费学习笔记（深入）”；
- 自动判断
response.ok并 throw 错误 - 默认加
Content-Type: application/json - 统一处理 token、超时、重试（可选）
这样既保持轻量，又避免重复踩坑。
团队协作或已有成熟规范，优先 axios
多数企业级项目已沉淀出基于 axios 的请求层（如统一错误码处理、权限跳转、日志上报），直接复用比重复造轮子更高效。维护成本低，新人上手快，生态插件也丰富（如 axios-retry、axios-cache-interceptor）。
不复杂但容易忽略：fetch 和 axios 都不处理跨域问题本身，CORS 仍需后端配合；超时控制在 fetch 中靠 AbortController，axios 中用 timeout 配置即可。
