Hello，大家好，我是 Sunday。

這幾年幫同學(xué)看代碼的時候，最常見的一個場景就是寫接口請求。很多同學(xué)也不用想，直接就上 axios！這點我完全理解，誰沒用過 axios 呢？社區(qū)成熟、文檔齊全、配置靈活，堪稱“前端請求的萬金油”。

但今天我想和你聊一個我最近用得非常爽的庫 —— Alova.js，它真的讓我意識到：我們對請求的認(rèn)知，是時候升級了！。

一、為什么我開始反思 Axios？

先說結(jié)論：不是 Axios 不好，而是它的設(shè)計理念已經(jīng)跟不上現(xiàn)在前端的節(jié)奏了。

想當(dāng)年，前端項目只是一些頁面交互，接口調(diào)用簡單粗暴，能發(fā)請求、能拿數(shù)據(jù)就夠用了。那時候，Axios 簡潔的 API、瀏覽器和 Node 的雙端兼容、攔截器機(jī)制，確實讓人眼前一亮，迅速成為了“前端標(biāo)配”。

但問題是：時代變了，項目需求也變了。

現(xiàn)代前端開發(fā)越來越復(fù)雜，我們不再滿足于“能用就行”，而是對請求有了更多“工程層面”的訴求，比如：

• 請求是否支持 自動合并和去重？（重復(fù)請求真的太常見了）
• 頁面卸載后，請求能自動取消嗎？否則容易觸發(fā)狀態(tài)更新警告或內(nèi)存泄露。
• 多個組件用到了同一個接口，狀態(tài)怎么共享？難道還要封裝一個全局變量手動管理？
• 在 SSR 場景下，如何優(yōu)雅地預(yù)取數(shù)據(jù)并注入客戶端？
• 如何內(nèi)建支持 緩存策略、請求重試、上傳進(jìn)度監(jiān)聽 等需求，不需要每次都重復(fù)造輪子？

這一切問題的本質(zhì)是：我們需要的不只是一個能“發(fā)請求”的工具，而是一個能“管理請求”的體系。

而在這點上，Axios 不是不能實現(xiàn)，而是你得親自去封裝、去維護(hù)、去踩坑。久而久之，它就像是一個“半成品”，你得自己把它打造成一個完整的“請求框架”。

于是我開始思考：

有沒有一款庫，可以把這些“現(xiàn)代需求”作為基礎(chǔ)能力開箱即用？能讓請求邏輯變得更語義化、更聲明式？

二、Alova 這才是現(xiàn)代請求庫該有的樣子

用了一段時間 Alova 后，我只想說：前端請求寫法，真的可以很“前端”。

1. 請求自動管理

以前你要寫請求防抖、重復(fù)合并、取消，得加很多 if + flag + 計時器。

在 Alova 中，直接配置：

useRequest(userAPI.get(1), {
  dedupe: true,           // 自動合并重復(fù)請求
  abortOnUnmount: true,   // 組件卸載時自動取消
  retry: 3                // 自動重試 3 次
});

你寫的不是“邏輯代碼”，而是“聲明你的意圖”，這才是現(xiàn)代開發(fā)應(yīng)有的體驗。

2. 請求自動響應(yīng)式

Axios 返回的是 Promise，Alova 返回的是一組響應(yīng)式數(shù)據(jù)。

比如 Vue 中：

const {
  data,
  loading,
  error,
  send
} = useRequest(() => userAPI.get({ id: 1 }));

請求狀態(tài)直接解構(gòu)出來，loading、error、data 全部響應(yīng)式，配合 template 寫起來非常爽。

3. 類型推導(dǎo)全自動，不用再“data.data”了

你是不是經(jīng)常這樣寫？

// 在全局響應(yīng)攔截器里已經(jīng) return res.data 了
axios.get<Response<User>>('/api/user')
  .then(res => res.data); // 但你還得寫類型 + 再拆一層 .data

又寫類型、又解構(gòu) data，重復(fù)勞動太多。

Alova 直接根據(jù)你定義的 API 返回值，自動推導(dǎo)類型，用起來非常干凈。

const userAPI = {
  get: (id: number) => alovaInst.Get<User>('/api/user', { params: { id } })
};

const { data: user } = useRequest(userAPI.get(1));
// user 會被自動推導(dǎo)為 User 類型，無需額外聲明

4. 攔截器？不，我們要更優(yōu)雅的中間件

Axios 攔截器一多，debug 都是噩夢，尤其是 request/response 各種嵌套，順序出錯還難查。

Alova 用的不是“攔截器”，而是類似中間件的“請求鉤子”機(jī)制，寫起來更聚焦：

const alova = createAlova({
  beforeRequest: (method) => {
    method.config.headers.token = getToken();
  },
  responded: (response) => response.json()
});

三、小總結(jié)

如果你目前的項目：請求多，重復(fù)邏輯封裝比較多，并且有明顯的封裝痛點，比如：緩存、上傳、錯誤處理 等。那么可以考慮使用下 Alova。

在使用 Alova 的時候，可以讓你的舊頁面繼續(xù)使用 axios，只在新功能中使用 Alova，這樣替換的風(fēng)險會更低。