Axios vs Fetch —— 我在用什么，以及那些踩過的坑
在 JavaScript 里發起 HTTP 請求，最常見的兩個方案是：
- 原生的 fetch API
- 第三方庫 Axios
我都在生產環境里用過。兩者都好用，但也各有“后悔 moment”。下面是我現在的選擇標準，以及被現實教育過后的注意事項。
快速縱覽
Feature | fetch（原生） | Axios（庫） |
是否內置 | ? 是 | ? 否（需安裝） |
JSON 解析 | ? 手動 | ? 內置自動 |
請求/響應攔截器 | ? 無 | ? 有 |
超時支持 | ? 需手動實現 | ? 內置 |
錯誤處理 | ? 僅網絡錯誤會拋 | ? 非 2xx 也當錯誤 |
上傳進度 | ? 實現較繁瑣 | ? 內置支持 |
體積 | ? 0 KB | ? ~14 KB（min） |
我喜歡 fetch 的點
自帶、零依賴無需安裝或引包——現代瀏覽器直接可用，Node 也能通過 node-fetch 使用。
配合 async/await 可讀性好
const res = await fetch('/api/data');
const data = await res.json();適合“自己把控細節”的場景小型應用或腳本里，我愿意手動處理邊界，更可控。
我對 fetch 的遺憾
不會自動解析 JSON每次都要 await res.json()，不難，就是重復。
無內置超時得用 AbortController，對新手略顯“別扭”。
const controller = new AbortController();
const timeout = setTimeout(() => controller.abort(), 5000);
const res = await fetch('/api/data', { signal: controller.signal });HTTP 錯誤不會拋出fetch 只在網絡層異常時拋錯，404/500 自己判：
if (!res.ok) throw new Error('Something went wrong');喜歡 Axios 的點
開箱即用、樣板代碼更少JSON 解析、常用頭、錯誤處理都幫你做好了。
錯誤流更干凈404、500 等直接拋錯，讓 try/catch 真正有意義。
請求/響應攔截器可全局加 token、打日志、統一處理錯誤等：
axios.interceptors.request.use(config => {
config.headers.Authorization = `Bearer ${token}`;
return config;
});文件上傳、大型前端項目友好進度跟蹤、表單數據等都更順手。
我對 Axios 的遺憾
多了一個依賴做小工具或一次性腳本時，不想為了簡單的請求引庫。
前端體積成本雖然不大，但當你極致優化時，~14 KB 也得算賬。
封裝比較深抽象層多了，偶爾定位問題比 fetch 更“黑盒”。
?? 我的選擇法則
使用場景 | 我更傾向 |
快速腳本 / 小項目 | fetch |
生產級前端應用 | Axios |
需要全局錯誤處理 | Axios |
堅持零依賴 | fetch |
文件上傳 / 需要進度條 | Axios |
收個尾
兩者都很優秀，但發光的場景不同：
- 輕量腳本、試驗性項目：我用 fetch。
- 追求開發體驗、需要全局攔截/錯誤治理：我選 Axios。
最好玩的是：你也可以用一層輕封裝把 fetch 改造成“類 Axios”，既保留零依賴的瘦身優勢，又獲得更順手的 DX。
你在項目里更常用哪一個——Axios 還是 fetch？ 有沒有讓你“真香”或“后悔”的經歷？
