reqable 隱藏功能挖掘：你以為它只是抓包工具？其實還藏著這些
reqable 是什麼
reqable 是一款把 HTTP 抓包與 API 測試兩件事合二為一的網路調試工具，主打一個「實時」——無論是 Android App 的 HTTPS 請求還是桌面應用的接口呼叫，只要設好代理或協同模式，流量就會源源不斷地灌進它的介面裡。
它的定位其實挺有意思：桌面端是功能滿配的主力（重寫、斷點、腳本、網關這些硬核能力全在這裡），移動端則主打輕量抓包——手機裝上就能直接攔截 App 流量，不用連電腦。五個平台一套主版本號，更新頻率基本以周為單位推進。如果你做移動端開發、接口測試、或者純粹想搞清楚某個 App 在背後偷偷發了什麼請求，reqable 是目前為數不多的選擇裡性價比不錯的一個。
安裝
reqable 的安裝體驗在五個平台上差異頗大，選對合適的形態能省不少麻煩。
Android 端就是 reqable下載 頁裡提到的那個 30.80MB 的 APK（版本 3.0.30），安裝本身沒什麼門檻——允許未知來源就能裝上。但裝完必須解鎖根證書安裝才能抓 HTTPS 流量：打開 App 側邊欄的「證書管理」，裡面會引導你一步步把 reqable 的根證書寫進系統證書存儲。這步如果跳過，你看到的請求體全是加密亂碼。另外 Android 端有個好處是能直接識別流量所屬的應用，iOS 因系統限制做不到這點。
reqable 桌面端（Windows / macOS / Linux）才是功能完全體。Windows 同時提供安裝程式和免安裝綠色版兩種形態，一般推薦安裝程式版——它會自動關聯 HAR 檔案格式，之後從瀏覽器匯入抓包記錄會方便很多。macOS 記得選對 Apple 晶片還是 Intel 晶片的 DMG，也支援用 Homebrew 一行命令裝。Linux 是 GTK 依賴的 deb 包，apt 一行搞定。桌面端安裝完啟動時，同樣需要把根證書加到系統信任鏈裡，官方文檔對每個作業系統的操作路徑都列得很細。
引子：大家通常怎麼用它
大多數人接觸 reqable 無非兩個場景：一是想看看某個 App 在幹嘛，裝個手機版就能抓；二是接口測試不滿足於 Postman 的黑盒，想在抓包過程中動手改幾個參數重發。但這兩種用法其實都只碰到了 reqable 表層的功能。我把它翻了個底朝天之後，發現不少藏得頗深的技巧——有些官方文檔提了但沒加粗，有些甚至只散落在 FAQ 裡。下面按「對誰有用、在哪開、什麼場景真能派上場」的標準，挑幾個最值得挖出來說的。
隱藏技巧一：移動端長按 Logo 看日誌
這是我偶然發現的——在 Android 端 App 的側邊欄，長按頂部那個 reqable 的 Logo，會彈出一個隱藏選單，讓你選擇檢視日誌檔案。
為什麼說它隱藏？因為這個功能完全沒有按鈕提示，你不長按根本不知道它存在。官方文檔裡提了，但就一行話藏在 FAQ 的最後面，很容易錯過。
什麼場景有用？當你手機端連不上電腦協同、或者抓包什麼都沒顯示的時候，先別急著卸載重裝——打開這個日誌看看。九成以上的問題（比如證書安裝失敗、協同連線被防火牆擋、VPN 權限被系統回收）在日誌裡都有明確的錯誤訊息，比瞎猜強太多了。這招對任何用移動端的人都有用，無論是開發者還是純好奇的玩家。
隱藏技巧二：Python 腳本的 shared 變數陷阱
如果你在桌面端用 Python 腳本做流量調試（比如 onRequest 裡改 header、onResponse 裡篩掉某個參數），你大概率會遇到這個坑：在 onRequest 裡設了一個模組級全域變數，到 onResponse 裡讀不到——變數丟了。
這不是你的 Python 寫錯了，是 reqable 的腳本執行模型決定的：onRequest 和 onResponse 跑在兩個不同的進程裡，模組級全域變數在進程間本來就不通。官方解決方案是用 CaptureContext 的 shared 變數——它是 reqable 提供的跨進程資料共享機制，寫法大概像這樣：
def onRequest(ctx, request):
ctx.shared["token"] = request.headers["Authorization"]
def onResponse(ctx, response):
token = ctx.shared.get("token", "")這個坑為什麼值得說？因為官方文檔對腳本 API 的進程模型著墨不多，很多人踩了之後以為是自己代碼寫錯，反覆排查浪費時間。什麼人用得上？寫腳本做複雜調試的開發者。純抓包看請求的人可以無視。
隱藏技巧三：JSON 請求體裡直接引用環境變數
API 測試功能裡有個小細節：請求體裡可以直接寫 ${變數名} 來引用環境變數，reqable 發送時自動替換成對應的值。
舉個例子，你在環境變數裡設了一個 token，值為 Bearer xxxxxx，那請求體 JSON 裡就能直接寫：
{
"authorization": "${token}",
"data": "..."
}
這個功能藏在哪？在 API 請求編輯頁的 JSON 編輯器裡，打開環境變數面板設定好變數後，編輯器旁邊會有一個小提示說明支援 ${} 語法，但不是所有人都會注意到。很多習慣手動複製貼上 token 的人，會發覺自己每次換環境都要改請求體——其實設一個環境變數就解了。
對誰有用？經常切換測試環境（開發環境 / 預發佈環境 / 正式環境）的開發者，或者同一組接口需要不同鑑權 token 的場景。
隱藏技巧四：斷點的線程池上限
斷點功能可以讓請求暫停下來讓你手改 header 或 body，但它有個隱藏的硬限制：每個斷點請求占一個獨立線程，超過線程池上限之後，後續請求不會進入斷點——直接被放行。
官方文檔只在 FAQ 裡順帶提了一句「高頻接口請改用重寫或腳本」，但沒說為什麼。原因就在這裡：如果你的 App 每秒發幾十次心跳請求，而你對所有請求都設了斷點，線程池很快就被占滿了——後面的請求根本等不到進入斷點。這個現象很容易讓人誤以為「斷點規則沒生效」，其實是線程被占滿了。
什麼場景用得上？有大量高頻接口的應用（即時聊天、心跳輪詢、實時資料同步這類），這些場景下斷點基本不好使，改用重寫規則或 Python 腳本才是正確姿勢。低頻接口（比如用戶註冊、訂單提交）用斷點完全沒問題。
隱藏技巧五：協同模式的自動發現與令牌機制
手機連電腦協同，大家通常想到的是掃二維碼。但其實 reqable 支援同區域網自動發現——手機和電腦在同一個 Wi-Fi 下，打開協同模式，手機端會自動掃描網路上可連接的裝置，直接點擊添加就行，連二維碼都不用掃。
更隱藏的是裝置令牌機制：在桌面端的裝置面板裡，對本機點三個點可以編輯「裝置令牌」。同樣令牌的裝置之間可以互相自動發現——這在多個開發者共用一個 Wi-Fi 的環境下特別有用，各自的手機只會發現設定了相同令牌的電腦，不會冒出一堆不相關的裝置。
這個功能的入口藏得頗深，官方首頁截圖裡也不會顯示令牌設定。對誰有用？多裝置開發場景下反覆連接的人，或者不想每次都掃碼的懶人。
提醒：幾個容易踩的坑
說完好的，幾個坑提前提醒一下。
第一，移動端沒有腳本功能。 這不是 bug 是設計——官方為了防濫用，把重寫、斷點、腳本這些調試能力全留在桌面端。如果你想在手機上用腳本處理流量，必須走協同模式，讓手機流量轉發到電腦端再處理。
第二，手機 IP 變了自動重連會失敗。 reqable 記住的是電腦的 IP 和端口，電腦切 Wi-Fi 之後 IP 變了，自動重連會掛掉。重掃一次二維碼就好了，別在那盯著手機發怒。
第三，腳本控制台關了就沒輸出了。 跑腳本時如果把編輯器窗口關掉，控制台報錯也一起消失。官方文檔明確說了要保持腳本編輯器窗口打開，我還是經常忘。
收尾
reqable 從一個「抓包工具」到一套完整的網路調試工作流，其實還有不少細節值得深挖——API 集合的批量匯入匯出、cURL 雙向轉換、網路條件模擬、HAR 檔案匯入分析……這些功能不是不宣傳，而是藏在設定面板的各個角落裡，需要你真的天天用才會慢慢發現。
我的感受是：工具的上限從來不是功能列表決定的，而是你願不願意翻一遍它的設定選單。把它用透，比換一堆工具更有效。
本文為個人基於網路公開資料整理編寫，非官方內容，僅供學習交流參考；軟體版權歸原作者所有，請支持正版；使用過程中遇到問題請查閱官方管道，本文不承擔任何責任。
