axios 1.20 评估：浏览器与 Node.js 共用的请求层，值得换掉 fetch 吗

它解决的是双端请求不一致的问题

axios 自称是浏览器和 node.js 的 Promise 风格 HTTP 客户端。这个定位意味着它想消除一个实际痛点：浏览器里你用 XMLHttpRequest 或 fetch，Node 里你又得换一套 API，错误处理、超时设置、请求取消的写法全都不一样。axios 把这两端包在同一个接口后面，你在浏览器写的代码，在 Node 里跑起来行为基本一致。它的目标用户很明确，就是那些需要同构代码的开发者。纯前端项目用原生 fetch 就够，纯后端项目用 undici 或 node-fetch 也顺。只有当你同时维护两端，或者项目可能从一端迁到另一端时，axios 的抽象才真正值钱。

适配器机制：同一接口，两套底层

axios 的核心是适配器（adapter）概念。在浏览器里，它默认走 XMLHttpRequest；在 Node.js 里，它走 http 或 https 模块。这个设计让上层 API 完全一致，但底层行为却有差异。文档没有细说适配器接口的完整签名，但从仓库结构能看出，axios 允许你自定义适配器，这意味着你可以替换掉默认的 XHR 或 Node 实现，比如换成 fetch 适配器。这种可插拔设计是它的优势，也是复杂度来源。你写的代码面对的是 axios 的配置对象，而不是原生 fetch 的 Request 和 Response。一旦你深入到底层，就得同时理解两套运行时行为，比如浏览器里的跨域限制和 Node 里的代理设置，它们并不完全对等。

拦截器才是它真正吸引人的地方

axios 的拦截器允许你在请求发出前和响应返回后插入逻辑。文档里给出的典型用法是请求拦截器里加 token，响应拦截器里统一处理错误。这个机制比 fetch 的 wrapper 函数更系统，因为拦截器是 axios 内部流程的一部分，可以叠加多个，并且支持异步。你可以把鉴权、日志、重试、错误上报都拆成独立的拦截器，而不是在一个大函数里堆 if else。代价是调试时你得记住拦截器执行的顺序，请求拦截器按添加顺序执行，响应拦截器按相反顺序执行，这个细节在文档里有说明，但新手容易踩。拦截器也增加了隐式行为，你看到的请求代码可能不是真正发出去的请求，因为中间被改过了。

从安装到第一次请求：实际命令与配置

安装 axios 很简单，npm install axios 即可，仓库没有给出更复杂的安装步骤。引入后，最基本的用法是 axios.get('/user?ID=12345')，它返回一个 Promise。配置通过对象传递，比如 axios.get('/user', { params: { ID: 12345 } })，params 会被序列化到查询字符串。你还可以用 axios({ method: 'post', url: '/user', data: { name: 'Fred' } }) 这种完整形式。超时、请求头、响应类型都在 config 里设置，文档举例包括 timeout、headers、responseType 等。这些配置键是 axios 的核心契约，熟悉它们比熟悉 fetch 的选项更繁琐，但换来的是两端一致的行为。注意，axios 不会自动处理响应里的 JSON，你需要自己调用 response.data 并决定是否 JSON.parse，这跟 fetch 的 res.json() 是不同思路。

v1.20 的发布节奏与维护状态

仓库显示默认分支是 v1.x，最近一次推送是 2026 年 8 月 24 日，同一天发布了 v1.20.0。往前看，v1.19.0 在 2026 年 7 月 26 日，v1.18.1 在 6 月 21 日。这个节奏大约是每月一个 minor 版本，说明项目还在活跃维护。但仓库没有提供变更日志的细节，所以 v1.20 具体改了什么，本文无法确认。从版本号看，v1.x 已经持续多年，API 稳定性有保障。对于工程团队来说，这意味着升级风险相对可控，但你也得接受一个现实：axios 的 core 已经定型，新版本带来的更多是 bug 修复和边缘情况处理，而不是新功能。如果你期待它跟上 fetch 的某些新特性，比如流式请求体，可能要等很久。

限制与失败模式：不是所有场景都合适

axios 有几个明显的短板。第一，浏览器端默认依赖 XMLHttpRequest，这意味着它不支持 fetch 的流式读取，比如读取响应体的一部分。第二，包体积比原生 fetch 大，因为它要打包两套适配器逻辑。第三，错误处理模型是抛异常，所有非 2xx 状态码都会触发 reject，这跟 fetch 只在网络错误时 reject 不同。如果你习惯了 fetch 的 then 里检查 res.ok，axios 的行为会让你意外。第四，取消请求的机制在 v1.x 里用的是 AbortController，但文档没有详细说明，实际使用时你需要自己封装。这些限制意味着 axios 不是万能的，尤其在需要精细控制网络栈或追求最小包体的场景，它可能是错误的选择。

与原生 fetch 的实质差异

最直接的替代方案是浏览器和 Node.js 18+ 自带的 fetch。两者的核心差异不在功能，而在抽象层次。fetch 是 Web 标准，接口基于 Request 和 Response 对象，流、重定向、缓存都有标准语义。axios 是库，它提供的是配置对象加 Promise，默认行为更贴近开发者习惯，比如自动把对象序列化为 JSON 请求体，而 fetch 需要你手动 JSON.stringify 并设置 Content-Type。axios 的拦截器没有原生等价物，你只能自己包一层函数。另一个差异是错误处理，fetch 只在网络层失败时 reject，axios 把 HTTP 状态码也算作错误。如果你的团队已经熟悉 fetch 标准，axios 的学习曲线是多余的；如果你的团队需要统一的请求管道，axios 的拦截器和默认行为能省不少胶水代码。

许可证与升级成本

axios 使用 MIT 许可证，这意味着你可以自由使用、修改和分发，只要保留版权声明。对于商业项目，这几乎没有法律负担。升级成本方面，v1.x 分支的语义化版本控制意味着 minor 版本应该保持向后兼容，但仓库没有提供迁移指南，所以从 v1.19 升到 v1.20 前，你应该跑一遍自己的测试套件，特别是涉及拦截器和取消请求的部分。axios 的配置 API 已经稳定多年，但底层适配器行为可能随 Node 版本变化，比如 Node 的 http 模块改动会影响 axios 的默认行为。长期维护这个库，你需要关注两个地方：一是依赖的 Node 版本是否在支持范围内，二是浏览器端的 XHR 是否会被新标准淘汰。就目前来看，XHR 短期内不会消失，但 fetch 的普及会让 axios 的适配器优势逐渐变小。

编辑结论

axios 适合需要统一浏览器和 Node.js 请求行为的团队，尤其是已经依赖拦截器做鉴权、日志或重试的老项目。它不适合只跑在 Node.js 18+ 且请求逻辑简单的场景，原生 fetch 更轻。也不适合对包体积极其敏感的边缘设备，XHR 适配器会拖累首屏。引入前先确认两点：一是你的 Node.js 版本是否支持原生 fetch，二是团队是否愿意接受 axios 的配置对象风格，而不是 fetch 的 Request/Response 标准接口。若两者都不成立，axios 的收益主要在拦截器和默认行为一致性上，值得保留。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes