我為什麼還會在 JavaScript 專案裡保留 Axios

截至 2026-06-20，axios/axios 在 GitHub 上仍然持續更新，而且星數已經超過 10 萬。這件事本身就很有意思，因為它說明 Axios 並不是那種「曾經流行、現在只剩回憶」的工具；相反地，它還在真實專案裡扮演一個很務實的位置。對我來說，Axios 的價值從來不是「比原生 API 更炫」，而是它把 HTTP 請求這件事，收斂成一個比較好治理、比較好封裝、也比較好維護的工程介面。

我現在看一個 HTTP client，會先問三件事：第一，能不能讓請求邏輯集中管理；第二，能不能把錯誤、逾時、取消、驗證這些邊界條件統一起來；第三，能不能在前端與 Node.js 之間維持一致的使用方式。Axios 之所以還會留在我的工具箱裡，就是因為它在這三件事上都做得夠穩，不需要我把很多配套自己重新拼起來。

先講結論：Axios 的價值不是「多一個 HTTP 套件」，而是「多一層可控的請求介面」

如果你只是做一個很小的頁面，偶爾打一兩個 API，其實原生 fetch 已經足夠。但一旦你的專案開始有以下情境，Axios 的優勢就會變得很明顯：

你想統一 baseURL、逾時、認證標頭與錯誤格式。
你想在請求發出前先補 token，回應回來後先做攔截或重試。
你想把同一套請求方法同時用在瀏覽器與 Node.js。
你不想每個團隊成員都自己寫一套錯誤處理與取消邏輯。
你想讓 API client 像一個模組，而不是散落在各個頁面與元件裡的臨時程式碼。

Axios 的 README 把它的能力講得很直接：支援瀏覽器請求，也支援 Node.js；以 Promise 為核心；可以攔截請求與回應；可以做資料轉換；支援請求取消；自動處理 JSON；也能處理表單序列化。這些能力單看每一項都不稀奇，但疊在一起，就會變成一個很適合專案化的請求層。

我不會把原生 fetch 和 Axios 當成非黑即白

我不是那種會說「有了 Axios 就不要用 fetch」的人。我的看法剛好相反：fetch 很適合做最底層的請求原語，而 Axios 比較像是把這些原語包成更適合團隊合作的介面。

1. `fetch` 很乾淨，但乾淨不等於完整

fetch 的優點是標準、原生、可預期，而且在現代瀏覽器和 Node.js 環境裡都越來越好用。可是如果你真的開始做團隊級的 API 封裝，就會很快碰到幾個現實問題：

逾時要自己包。
錯誤格式要自己整理。
成功與失敗的回應資料結構要自己統一。
token 更新、刷新與重試要自己串。
每個頁面各寫一段，最後就變成難以維護的複製貼上。

這不是說 fetch 不好，而是說它比較像地基，不像成品介面。Axios 在這中間補上的那一層，剛好就是很多團隊真正缺的部分。

2. 攔截器是 Axios 最實用的設計之一

我認為攔截器是 Axios 最值得保留的功能。因為它讓請求前後的處理可以集中在一個地方，而不是散在每一個呼叫點。像是：

請求前自動加上 Authorization。
回應後統一處理錯誤代碼。
遇到 401 時先嘗試刷新 token。
把後端回傳的錯誤格式轉成前端可以直接顯示的結構。

這些事情如果沒有攔截器，通常就會演變成很多重複程式碼。對我來說，這才是 Axios 的核心價值：它不是幫你少打幾個字，而是幫你少散掉很多責任邏輯。

3. 取消請求與逾時，決定了它是不是能進正式流程

很多人只在 demo 裡用 HTTP client，完全不覺得取消請求重要。可是只要你做過搜尋、自動補全、切換頁面、上傳檔案、或可中斷的工作流，你就知道取消請求不是可有可無。

Axios 已經支援 AbortController，這很關鍵。因為這代表它和現代 Web API 的方向是一致的，而且新專案不用再依賴已經被棄用的 CancelToken。對我來說，這種「跟得上現代平台的設計」，比單純功能多寡更重要。

如何開始使用 Axios

如果你剛接手一個專案，或你想把 Axios 放進新服務，我會建議你用很務實的方式開始。

前置條件

你已經有一個 JavaScript 或 TypeScript 專案。
你知道自己的 API 會打到哪個基底網址。
你知道前後端是否共用同一個登入憑證或 token 機制。
你願意把 API 呼叫集中成一個模組，而不是散在頁面裡。

安裝

Axios 的安裝方式很直接，README 也列得很清楚：

npm install axios

如果你習慣用 yarn、pnpm 或 bun，也可以照對應套件管理器安裝。重點不是哪一個工具，而是你要先把它視為「請求層依賴」，而不是「某個頁面臨時加上去的套件」。

第一次請求

我會先從最小可驗證任務開始，也就是打一個 GET，確認安裝、匯入、回應解析都正常。

import axios from 'axios';

async function loadUser() {
  try {
    const response = await axios.get('/api/user', {
      params: { id: 12345 },
    });

    console.log(response.data);
  } catch (error) {
    console.error('請求失敗：', error);
  }
}

這段程式碼的重點不是它很短，而是它已經把幾個核心概念串起來了：

axios.get 是 Promise 型介面。
response.data 是你真正要處理的資料。
catch 讓你有統一的失敗入口。

如果這一步能正常運作，你就可以往下做封裝，而不是先急著設計一整套過度複雜的 API 層。

建立實例，把共通設定集中起來

這是我最推薦的第二步。不要讓每一個 API 呼叫都自己帶 baseURL、timeout、token 或雜亂的標頭。建立一個實例，把共通設定集中起來，才有辦法維持一致性。

import axios from 'axios';

export const api = axios.create({
  baseURL: 'https://api.example.com',
  timeout: 10000,
  headers: {
    'Content-Type': 'application/json',
  },
});

接著你可以開始在這個實例上掛攔截器。

api.interceptors.request.use(
  (config) => {
    const token = localStorage.getItem('token');
    if (token) {
      config.headers.Authorization = `Bearer ${token}`;
    }
    return config;
  },
  (error) => Promise.reject(error),
);

api.interceptors.response.use(
  (response) => response,
  async (error) => {
    if (error.response?.status === 401) {
      // 這裡可以接續刷新 token 或導向登入頁
    }
    return Promise.reject(error);
  },
);

這一步做完，Axios 才真正開始顯示出它的工程價值。因為你不是在處理單次請求，而是在定義整個專案的請求規範。

取消請求：這個功能值得你現在就用起來

如果你的頁面有搜尋、即時篩選或快速切換資料的需求，我會建議你直接把 AbortController 放進去。

import axios from 'axios';

const controller = new AbortController();

async function searchUsers(keyword) {
  try {
    const response = await axios.get('/api/users', {
      params: { q: keyword },
      signal: controller.signal,
    });

    return response.data;
  } catch (error) {
    if (error.name === 'CanceledError') {
      console.log('請求已取消');
      return;
    }
    throw error;
  }
}

// 當使用者切換條件或離開頁面時
controller.abort();

我喜歡這種寫法，因為它很明確地把「這個請求只在當下有意義」表達出來。這比事後再猜是不是 stale response，來得更乾淨。

我會怎麼把 Axios 用成可維護的專案資產

如果只是拿來打一支 API，任何套件都差不多。但如果你想讓它變成團隊資產，我會建議你至少做下面這些事：

把所有 API 呼叫收斂到單一模組。

不要在頁面、元件或 hook 裡亂打 axios.get。

建立一致的錯誤格式。

不管後端回傳什麼格式，前端都應該只面對一種錯誤結構。

統一 timeout 與 baseURL。

不要讓每個呼叫點自己決定逾時，否則排錯會很痛苦。

把 token 與權限處理放進攔截器。

這樣你才能確保所有請求都遵守同一套規則。

把取消請求當成標配。

尤其是有互動密集場景的產品，這不是優化，而是體驗基本盤。

不要過度封裝到看不懂。

有些團隊把 Axios 包成一層又一層，最後連自己都找不到錯誤來源。封裝的目的是治理，不是把複雜度藏起來。

我會在什麼情況下不用 Axios

這一段我也想講清楚，因為我並不是 Axios 的無條件支持者。

我可能不用它的情況

專案非常小，而且只有少量請求。
你已經有非常成熟的 fetch 封裝，而且團隊維護得很好。
你不需要攔截器、取消、統一錯誤或複雜的共通設定。
你想把依賴數量壓到最低。

我會保留它的情況

你的專案有多個 API 來源。
你的前端與 Node.js 服務需要共用請求風格。
你需要做 token、刷新與權限處理。
你想把 API 交互變成可測試、可替換、可治理的模組。

換句話說，Axios 不適合所有場景，但它非常適合那些已經開始有「團隊工程問題」的場景。當請求層不再只是請求層，而是整個產品可靠性的一部分時，Axios 的價值才會被放大。

我的判斷：Axios 不是最時髦的答案，但它是很穩的答案

我喜歡 Axios，不是因為它有什麼讓人驚艷的黑科技，而是因為它把幾件最常見、最容易出錯的事情做得很順：攔截器、取消、JSON、表單、Node.js 與瀏覽器一致性。這些能力看起來都很務實，卻正是很多真實專案最需要的。

如果你問我，Axios 值不值得留在專案裡，我的答案會是：只要你的請求層開始需要治理，而不是只需要發送資料，那它就仍然值得。它不是那種會讓你一眼驚呼的工具，但它很可能是那種在你把專案做大之後，最不會後悔留下來的工具之一。

參考資料