團隊裡禁用了一種調味包，而廚房裡的老師傅早就懂這件事

2026 年 10 月 20 日，掘金上出現一篇標題很衝的文章：一位前端工程師 ErpanOmer 寫下「為什麼我在團隊裡禁止使用 axios」。規則寫在工程規範文件裡：新專案禁止引入，舊專案在下一輪重構週期內逐步移除。內部羣組立刻炸鍋，有人喊著用了好幾年很穩，有人貼表情包抗議。

這則技術圈的爭執，讀起來卻像一間餐廳後廚裡的老故事。

axios 之於前端工程師，就像市售的綜合調味包之於家庭廚房。入行第一天就在用，打開就能下鍋，鹹淡早就配好了，你從來不需要問裡面放了什麼。這位作者也說了公道話：2016 年前後，瀏覽器原生的 fetch 剛落地，那時它像是只用一種火力的爐子，不能調溫、不能計時，出鍋失敗了還不會告訴你原因。調味包在那個年代是救命的。

但到了 2026 年，他攤開 MDN 文件一看，原生的爐子早就升級了。當年調味包最核心的三個賣點，攔截器、超時、取消，要嘛原生已經支援，要嘛用不到十行碼就能自己配。反倒是他真正需要的能力，例如流式響應、大文件傳輸，像大火快炒那種需要持續控火的功夫，調味包給不了。

他在文章裡列了三個實際痛處，每一個都聞得到廚房的熟悉味道。

第一個是攔截器。他們的專案裡掛了四層：鑑權注入、日記埋點、錯誤統一處理、灰度標記，請求與回應各四個，總共八個。一個請求發出去，要經過四層攔截器的變形才真正抵達網路層；回應回來，又要過四層加工才到達業務代碼。任何一層吞掉錯誤、改了標頭、忘了回傳，都很難定位。這就像一道菜出鍋前要過四個人的手，每個人都順手補一點醬、撒一點鹽，最後味道不對了，沒有人說得清是哪一勺出了事。

第二個是取消機制。axios 的 CancelToken 在 v0.22.0 就被官方標記為廢棄，建議改用 AbortController。但他們的代碼庫裡有幾十處舊用法，沒人敢動，理由是「改了怕出事，不改跑著也沒問題」。於是新舊兩套機制並存，維護成本翻倍。這廚房裡太常見了：調味櫃深處那罐過期的蠔油，你知道該丟，但那道家常菜一直靠它，誰也不敢先動手。

第三個更實際。他們有部分接口跑在 Cloudflare Workers 上，那個環境原生支援 fetch，卻不支援 axios 依賴的 XMLHttpRequest 與 Node 的 http 模組。為了讓 axios 跑起來，團隊得額外引入適配層。用廚房的話說，就是為了一包現成調味料，專門去買了一臺不搭的攪拌機。

他的結論很樸素：用一個三十行左右的純函數封裝，替掉整個 axios。邏輯全部可見，沒有藏起來的攔截器鏈。這就像老師傅的立場，與其依賴一包你看不到配方的綜合調味粉，不如回到一把鹽、一勺糖、幾滴醬油，每一味都出自你自己的手，味道偏了你都知道往哪裡找。

這種「讓備料歸備料、爐臺歸爐臺」的固執，其實很多廚房早就在練習。我們之前寫過備料臺不能再偷拿爐臺上的東西，講的是另一條工程規矩裡同樣的分區邏輯：界線畫清楚，出了問題才知道往哪看。

不過文章裡也藏著一句值得咀嚼的話。他說，多數專案裡的 axios，已經從解決問題的工具，變成了不敢刪的歷史遺留。家庭冰箱裡誰沒有這樣的東西？那瓶醬料當年確實救過一桌菜，如今你甚至忘了當初為什麼買它，只是每次清冰箱，手都會繞過去。

當然，技術選型有它的脈絡，餐廳後廚也有它的現實。這篇文章是作者單一團隊的決策與觀察，換個廚房、換一批菜單，答案未必相同。但那個動作是通用的：每隔一陣子，把櫃子裡每一包、每一罐拿起來問一句，你現在還做得到什麼，是別的東西做不到的？

答不出來的，也許就到了說謝謝、然後放下的時候。無論是一個請求庫，還是一罐陳年的調味料。