我們為什麼開發 ApiCatcher？

大家好，我是 ApiCatcher 的創造者吳就業。我的工作經歷涵蓋 iOS 與 Android 應用開發、後端開發及中介軟體研發，2024 年創作了 ChatTCP，2025 年 12 月辭職創業，並於 2026 年 1 月創作了 ApiCatcher。今天我想與你分享為什麼要開發這款 HTTPS 抓包工具。

在過去的工作中，每次換工作都要面對陌生的專案，而且幾乎沒有技術文件與 API 文件。每當接到新任務需要改一個功能、評估此次需求會影響哪些 API 時，我都得花大量時間閱讀程式碼，才能找到相關的 API。

2025 年，我從中介軟體研發轉做後端開發，開始處理業務需求。有一件事讓我印象特別深刻：當時我沒有權限看客戶端的程式碼，也不曉得客戶端呼叫了哪些 API，而客戶端的同事同樣剛接手、對專案不熟悉。我不得不想辦法在沒文件、沒程式碼的情況下找出自己需要的 API。

本來可以在伺服器端抓包，但伺服器架構太複雜，連入口是哪個閘道都不知道，於是我只能嘗試在客戶端抓包。然而客戶端發出的請求是 HTTPS 加密的，我便開始尋找支援 HTTPS 抓包的工具。因為我的手機是 iPhone，我試用了幾款在 App Store 下載的 HTTPS 抓包工具，包括 Stream 和 ProxyPin。

當時我希望把這些 API 匯入 Apifox，並以此為基礎搭配新的迭代需求去修改，再在團隊中共享這份 API 文件。但開源工具基本上只有「抓包」這一個功能，我也試了一些付費抓包工具，卻沒有任何一款能滿足我的需求。最後我只能根據抓到的請求和回應資料，自己在 Apifox 裡手寫 API——這件事整整花了我一天半的時間。

我需要重現多種業務場景，多次抓包，再將多次請求的參數、請求 Body、回應 Body 合併成一份相對完整的 API 文件。因為在不同場景下呼叫 API 的參數不同，回應結果也不一樣。例如當簽收訂單的裝置類型是鏡頭時，需要傳鏡頭相關的參數；當裝置類型是電子鑰匙時，則需要傳鑰匙相關的參數。不同參數對應的回應欄位也會有差異，後端程式碼充滿了大量的 if-else 邏輯，從程式碼層面去理解非常痛苦。

那次經驗之後，我決定自己開發一款 HTTPS 抓包工具——這款工具要能自動產生 API 文件，多次抓同一 API 的請求後能自動更新文件、補充欄位，還能自動關聯抓包歷史記錄。最重要的是，能把產生的 API 文件匯出到 Apifox 或 Postman，同時附帶請求歷史作為測試案例。這樣我就能在 Apifox 中根據真實資料去分析和迭代 API 文件，並在團隊中共享。

將捕獲的 HTTPS 請求自動生成 API 文件、更新文件、將不同業務場景下捕獲的同一 API 請求歷史轉化為測試案例，並將文件與案例一同匯出到 Apifox 或 Postman——這就是這款工具最初的核心願景，也是我們在所有抓包工具中原創且獨有的功能。這就是我們取名 ApiCatcher 的原因。

後來在自己做專案、做全端開發的過程中，我發現對於前端／客戶端開發者（包括 Web、iOS、Android、Windows、macOS）來說，抓包工具不只是抓包，更是除錯 API 的利器。以前做後端開發時，我們可以用 API 管理工具測試，或自己寫測試案例，只要判斷 API 回應符合預期就好。但客戶端開發不一樣——客戶端需要驗證 UI 互動邏輯，這是腳本無法替代的，必須手動操作才能看到效果。客戶端只能透過程式碼 Mock 各種回應，但這樣會導致專案出現大量難以維護的 Mock 程式碼。如果抓包工具能支援 Mock 回應、模擬 API 回應耗時，就能解決客戶端開發中 API 除錯的痛點。另外，在前後端 API 聯調過程中，抓包工具對問題的排查分析也非常有幫助，能極快地定位問題——因為中間隔著底層網路框架，實際發出的請求不一定跟日誌看到的完全一致，請求耗時也不一定發生在客戶端程式碼。因此把 HTTPS 抓包和 API 除錯的需求整合在一起是非常有必要的。

在滿足 API 擷取與除錯需求的基礎之上，我們還希望打造一款真正注重使用體驗的工具，而非僅僅堆砌功能。因此我們在設計上考慮了很多細節。例如，在編寫重寫規則的正則替換規則時，由於正則表達式語法比較複雜，很多使用者不知道怎麼寫，我們就加入了 AI 生成表達式的功能，只要描述效果，AI 就會自動生成表達式。同樣地，在編寫定時任務的 Cron 表達式時，我們也加入了 AI 生成 Cron 表達式的功能。

在最需要的時候出現那個恰到好處的功能，就是我們在細節上的努力。我們致力於把 ApiCatcher 打造成一款使用體驗極佳的 HTTPS 抓包工具，幫助你提升工作效率。