入行這些年的一個真實經(jīng)歷前端同學(xué)信誓旦旦說頁面沒發(fā)請求后端同學(xué)說接口根本沒收到我跑到工位上一看兩邊都能理直氣壯誰也說服不了誰。最后我打開Fiddler抓包工具把手機、瀏覽器流量掛上代理十分鐘內(nèi)就發(fā)現(xiàn)是測試環(huán)境域名被緩存劫持到了舊網(wǎng)關(guān)請求壓根沒到后端。這種場景你大概率也遇到過——程序員的日常一半時間在寫代碼另一半時間在證明“不是我的鍋”。Fiddler抓包工具就是把這個“證明”過程變得可視化、可操作、可復(fù)現(xiàn)的工具。無論你是前端、后端、測試還是運維只要你的工作和 HTTP/HTTPS 接口沾邊Fiddler 都能幫你看到瀏覽器和手機 App 背后最真實的流量。它能看請求頭、響應(yīng)體、狀態(tài)碼、耗時、Cookie、重定向鏈能斷點篡改數(shù)據(jù)、能 Mock 接口、能保存會話做回歸對比。這篇文章不打算給你羅列菜單而是按我實際使用的路徑把從安裝到進階的流程、原理和踩坑經(jīng)驗一次性講透讓你能照著操作也能在出問題時知道去哪個設(shè)置里找原因。1. 從零跑通第一次抓包先弄清Fiddler在干什么1.1 代理是怎么一回事Fiddler 本質(zhì)上是一個本地代理服務(wù)器。你在瀏覽器或手機里設(shè)置代理地址為電腦 IP 加 8888 端口后所有HTTP/HTTPS請求都會先經(jīng)過Fiddler再由它轉(zhuǎn)發(fā)給目標服務(wù)器。服務(wù)器返回的數(shù)據(jù)也會先回到Fiddler再交還給你。所以“抓包”并不是偷看而是讓流量主動繞道經(jīng)過一個可以記錄和修改的中間點。這個機制的關(guān)鍵是“中間人”。你可以把它想象成快遞員正常情況下你的包裹直接由商家發(fā)到你手上中間人模式下包裹先送到中轉(zhuǎn)站中轉(zhuǎn)站拆開檢查、登記、甚至換掉里面的商品再重新封好發(fā)給你。Fiddler 就是那個中轉(zhuǎn)站。它拆包的依據(jù)就是你的代理設(shè)置這個設(shè)置只對當前配置的客戶端生效并不會影響其他設(shè)備。理解了這一點排查問題就順了。比如網(wǎng)頁能打開但Fiddler看不到任何會話先別懷疑軟件壞了99%的情況是代理沒有生效。Chrome 等瀏覽器如果要走系統(tǒng)代理需要確認啟動參數(shù)沒有被改或者插件強制了直連手機端則要確認代理 IP 和端口填對了并且電腦防火墻放行了 8888。這些都是新手最容易卡住的地方。1.2 安裝與初始配置安裝 Fiddler 沒什么門檻一路默認即可。我第一次裝完就急著抓 HTTPS結(jié)果發(fā)現(xiàn)全是“Tunnel to ...”明文字段一概看不到后來才知道還差兩步開啟解密開關(guān)和安裝證書。在你拿到一個舊版本時這兩個入口通常藏在 Tools Options HTTPS 里勾選“Capture HTTPS CONNECTs”和“Decrypt HTTPS traffic”然后按提示安裝根證書。初始配置里還有一個高頻坑默認只捕獲瀏覽器流量不捕獲系統(tǒng)服務(wù)或其他進程。新版入口可能在“WinConfig”或“System Proxy”相關(guān)位置你要確認“Capture Traffic”處于開啟狀態(tài)同時把 System Proxy 打開否則代理沒掛到系統(tǒng)上什么都看不到。建議安裝完先做一次最小驗證打開 Fiddler重啟瀏覽器訪問任意網(wǎng)站看會話列表有沒有出現(xiàn)記錄。有記錄說明代理鏈路已經(jīng)通了后面再逐步增加 HTTPS、手機端等能力。注意安裝證書后操作系統(tǒng)會信任 Fiddler 生成的根證書。不用時建議關(guān)閉解密開關(guān)或移除證書避免在公用環(huán)境留下不必要的信任風(fēng)險。1.3 第一個抓包實例觀察請求從哪里來到哪里去跑通代理之后我建議你先別急著看細節(jié)而是用 Fiddler 自帶的功能看一遍“請求生命周期”。隨便訪問一個測試站點點中會話列表里的一條請求右邊 Inspector 面板里能看到請求行、請求頭、請求體再點響應(yīng)區(qū)域能看到狀態(tài)行、響應(yīng)頭、響應(yīng)體。這里最關(guān)鍵的不是看懂每個字段而是建立“一對多”的感覺——你訪問一個頁面往往會產(chǎn)生幾十個請求真正想要的 HTML 只是其中一條其他是圖片、腳本、樣式、統(tǒng)計上報。你可以立即體驗過濾的必要性。在左下角 QuickExec 輸入框輸入?ts就只顯示 URL 里帶“ts”的請求輸入302只顯示 302 狀態(tài)碼輸入host:example.com只看某個域名的流量。這些過濾不是高深技術(shù)但它們決定了你能不能快速鎖定目標。我見過很多新人把幾屏請求從頭翻到尾十分鐘找不到接口我過去敲一個?api/列表瞬間干凈。工具的熟練程度很多時候就體現(xiàn)在這些不起眼的操作上。2. 看懂會話流識破每一次請求的“底細”2.1 會話列表字段的潛臺詞Fiddler 的會話列表Web Sessions默認顯示 Result、Protocol、Host、URL、Body、Caching、Content-Type 等字段。很多人只看 URL 和 Result其實前幾列的信息量被嚴重低估。Protocol 是 HTTP/1.1 還是 HTTP/2直接決定你后面分析連接復(fù)用和隊頭阻塞的方向。Caching 列的no-cache說明資源每次都要回源校驗private說明只能本地私有緩存這對排查“頁面更新了但客戶端還是顯示舊數(shù)據(jù)”至關(guān)重要。狀態(tài)碼也是很有講究的。200 不是唯一正常的答案304 表示緩存有效服務(wù)器沒有重新返回內(nèi)容這通常不是錯誤302 后面一定還有一個跳轉(zhuǎn)后的請求如果你只看到 302 沒看到后續(xù)可能是 Location 頭被攔截或客戶端沒有跟隨跳轉(zhuǎn)。404、500 大家都會看但容易被忽略的是 401 和 403前者是沒登錄后者是登錄了但沒權(quán)限排查時思路完全不同。我自己的習(xí)慣是點中一個會話按F12打開 Inspector然后從頭到尾讀一遍請求頭和響應(yīng)頭。大部分問題藏在細節(jié)里Host 是不是預(yù)期域名Content-Type 是不是表單Origin 和 Referer 是否被服務(wù)端校驗Cookie 傳遞是否完整Set-Cookie 的 Domain 和 Secure 標志是否設(shè)置正確。這些字段單個看都認識組合在一起才構(gòu)成完整的請求語境。2.2 請求與響應(yīng)在Inspectors里的對應(yīng)關(guān)系右側(cè) Inspector 上半部分是請求下半部分是響應(yīng)默認以分類視圖顯示但更推薦你用 Raw 視圖。Raw 視圖能看到完整的原始報文包括首部順序和不可見字符比如請求體末尾沒有換行符、響應(yīng)頭里有多余的空格這類問題只在原始報文里能發(fā)現(xiàn)。具體操作是選中會話點擊右側(cè)上方的“Raw”標簽?zāi)隳芸吹筋愃葡旅娴慕Y(jié)構(gòu)GET /api/users?a1 HTTP/1.1 Host: example.com User-Agent: Mozilla/5.0 Accept: */*下面空一行然后是請求體。響應(yīng)則顯示狀態(tài)行、響應(yīng)頭、空行、響應(yīng)體。這個結(jié)構(gòu)是 HTTP 協(xié)議的基礎(chǔ)Fiddler 只不過把它可視化。我常讓同事做一個練習(xí)不看 Fiddler 的分類視圖只看 Raw 報文嘗試說清楚這個請求的 Content-Length 和實際請求體長度是否一致。這個練習(xí)做完再看抓包數(shù)據(jù)就不再發(fā)怵了。2.3 狀態(tài)碼與耗時快速定位異常的三個指標除了狀態(tài)碼你還應(yīng)該盯三個時間指標DNS 解析時間、TCP 連接時間、請求響應(yīng)總時長。Fiddler 在 Statistics 面板會給出性能數(shù)據(jù)比如“Request count”“Total bytes sent”“Duration”。定位慢接口時先看總時長然后在時間線Timeline里看是哪個階段拖了后腿。如果 DNS 就花了 3 秒那和接口本身沒關(guān)系是本地 DNS 配置的問題如果 TTFB 很長但接收字節(jié)很快那就是服務(wù)端處理邏輯慢可以騰出手去查數(shù)據(jù)庫或者遠程調(diào)用。典型場景是 WebSocket 連接無法建立。此時會話列表出現(xiàn)的是 101 狀態(tài)碼這不算錯誤表示協(xié)議切換成功。如果抓包看到 101 之后馬上斷開重點看響應(yīng)頭里的 Sec-WebSocket-Accept 是否正確、代理是否對 Upgrade 頭做了攔截。Fiddler 默認能處理這類流量但如果你開了某些過濾規(guī)則把頭部改了就容易破壞握手。3. HTTPS流量解密證書的安裝與信任鏈邏輯3.1 為什么默認抓不到HTTPS明文HTTPS 的“S”代表安全套接層它讓傳輸內(nèi)容加密第三方即使截獲數(shù)據(jù)包也讀不出明文。Fiddler 想看到明文必須把自己變成客戶端信任的“合法”服務(wù)器。做法是Fiddler 生成一個根證書客戶端安裝并信任這個根證書后Fiddler 再為每個訪問域名臨時簽發(fā)一張子證書從而完成對目標服務(wù)器的“李代桃僵”。你可能擔(dān)心這是不是有風(fēng)險。公平地說任何中間人代理方案都有信任風(fēng)險Fiddler 只是在調(diào)試場景下讓你主動選擇信任它。個人測試自己的應(yīng)用完全沒問題前提是你清楚自己在做什么并且不要在他人不知情的情況下截取其設(shè)備流量。這里設(shè)置邊界很重要安裝證書的設(shè)備必須是你的設(shè)備目標系統(tǒng)必須是你有權(quán)限調(diào)試的系統(tǒng)。安全邊界抓包工具不能用來獲取別人賬號信息、繞過他人授權(quán)或入侵不屬于你的系統(tǒng)。它只是一個調(diào)試工具用途應(yīng)當在合法授權(quán)范圍內(nèi)。3.2 電腦端證書安裝與信任第一次開啟解密時Fiddler 會在“HTTPS”設(shè)置頁生成DO_NOT_TRUST_FiddlerRoot這樣的根證書。在電腦上安裝時務(wù)必通過系統(tǒng)證書管理入口導(dǎo)入到“受信任的根證書頒發(fā)機構(gòu)”不要只導(dǎo)入到“個人”證書。裝錯位置的典型癥狀是瀏覽器打開提示證書錯誤但 Fiddler 會話里又確實有流量。因為中間人證書不被信任客戶端就會在 TLS 握手階段拒絕連接。安裝完成后建議先重啟 Fiddler 和瀏覽器再訪問一個啟用 HTTPS 的站點。如果看到 URL 前面帶鎖會話列表里也不再是Tunnel to而是具體的GET請求說明解密成功。若仍然只能看到 CONNECT 隧道請依次檢查解密開關(guān)是否勾選證書是否在受信任根列表瀏覽器是否啟用了“安全 DNS”或“跳過本地代理”等干擾設(shè)置。3.3 移動端證書安裝與授權(quán)設(shè)置手機端抓包比電腦端麻煩但邏輯相同手機要連電腦的代理同時要安裝并信任 Fiddler 的根證書。證書傳遞一般有兩種方式一是通過手機瀏覽器訪問http://電腦IP:8888下載證書二是把FiddlerRoot.cer通過文件傳輸工具傳到手機再點擊安裝。安裝后還有一步容易漏不同系統(tǒng)的信任機制不一樣有些需要在“證書信任設(shè)置”里為 Fiddler 根證書開啟完全信任有些需要把它加入系統(tǒng)證書存儲區(qū)。如果你只做了安裝沒有信任Chrome 類瀏覽器可能仍然拒絕連接原生 App 則可能直接忽略證書。我見過很多人卡在“證書裝了但 App 依然超時”這一步其實就是沒去“信任證書”設(shè)置里手動打開開關(guān)。還有一點移動端 App 可能使用了證書綁定Certificate Pinning也就是客戶端內(nèi)置固定了服務(wù)器證書指紋。這種情況下即使安裝了根證書App 也不會認 Fiddler 動態(tài)簽發(fā)的證書表現(xiàn)為頁面直接無法打開或者報證書錯誤。這并不是你配置錯了而是應(yīng)用刻意防代理。常規(guī)調(diào)試遇到這種情況需要優(yōu)先確認自己是否有權(quán)修改該應(yīng)用或該設(shè)備否則不要輕易嘗試繞過。3.4 解密規(guī)則的開啟與核對默認情況下Fiddler 可以對所有 HTTPS 會話解密。為了性能和管理方便你可以在解密設(shè)置里添加例外規(guī)則比如只解密example.com或者排除所有指向某個 IP 的流量。規(guī)則寫的是通配符路徑用錯了會影響匹配范圍我見過有人寫*facebook*結(jié)果該域名下的所有子域都被解密列表刷到卡頓。每次改完解密規(guī)則記得清空一次會話列表CtrlX再重新驗證。因為舊會話里已經(jīng)記錄了未解密或已解密的報文不清理的話你會誤以為規(guī)則沒生效。另外一個高頻操作是“記住客服端證書”如果你在做雙向 TLS 驗證的調(diào)試需要額外配置客戶端證書這個功能在解密選項里很少人用但遇到銀行類接口調(diào)試時就是剛需。4. 斷點與篡改讓流量“中途停車”改數(shù)據(jù)4.1 斷點機制的觸發(fā)原理Fiddler 的斷點分為“請求前斷點”和“響應(yīng)前斷點”。請求前斷點發(fā)生在客戶端請求發(fā)出后、Fiddler 轉(zhuǎn)發(fā)到服務(wù)器前此時你可以修改請求頭、請求體、URL 參數(shù)響應(yīng)前斷點發(fā)生在服務(wù)器響應(yīng)已返回、Fiddler 交還給客戶端之前此時你可以修改響應(yīng)狀態(tài)碼、響應(yīng)頭和響應(yīng)體。這兩類斷點相互獨立可以同時開啟。最簡單的開啟方式是在 Fiddler 菜單選擇 Rules Automatic Breakpoints勾選“Before Requests”或“After Responses”。更靈活的方式是結(jié)合 QuickExec 命令比如輸入bpu example.com只有匹配該地址的請求才斷點輸入bpa響應(yīng)斷點bps狀態(tài)碼斷點。這種精準斷點非常適合只攔截一條接口其他流量正常放行。4.2 修改請求頭與請求體模擬不同客戶端修改請求頭最常用的場景是偽裝 User-Agent 或改造參數(shù)版本。比如你測試現(xiàn)網(wǎng)環(huán)境沒有 Android 類客戶端入口但服務(wù)端邏輯區(qū)分端別你就可以把抓到的請求復(fù)制到 Composer修改 User-Agent 后重放觀察返回差異。操作路徑是右鍵會話 Add to Composer然后在底部的 Composer 面板里編輯頭部。注意 Fiddler 的 Composer 默認可能帶Content-Length你修改請求體之后要手動更新長度或讓 Fiddler 自動重算否則服務(wù)器會因長度不匹配而拒絕請求。請求體的修改比頭部更簡單直接在 WebForms 或 Raw 面板里改字段再“Breakpoint”放行。這里有個細節(jié)如果你修改的是 JSON 格式 body建議在 Text 視圖里改改完確認一下 JSON 合法。曾經(jīng)有人把響應(yīng)里的status從success改成success多打了一個空格導(dǎo)致前端 JSON.parse 直接拋異常而他還以為是前后端 bug。4.3 修改響應(yīng)體制造前端臨界場景前端調(diào)試空狀態(tài)、錯誤狀態(tài)、超長列表時最討厭的就是等后端造數(shù)據(jù)。響應(yīng)前斷點可以讓你直接把后端返回改掉。比如你想模擬一個 500 錯誤就在響應(yīng)前斷點點中會話修改狀態(tài)行為 500再把響應(yīng)體換成自定義錯誤 JSON然后放行。客戶端看到的就和真實故障一模一樣。我更常用的場景是超時和無響應(yīng)開啟響應(yīng)前斷點后不點擊“放行”而是把會話一直掛在那里觀察前端是否會走超時邏輯。這比單純改狀態(tài)碼更貼近真實弱網(wǎng)環(huán)境。還有一種玩法是修改響應(yīng)頭里的 Cache-Control把no-cache改成max-age3600驗證前端命中緩存后是不是不再發(fā)請求。這些操作雖然簡單但能讓后端還沒開發(fā)完成時前端就能按約定字段開發(fā)界面。4.4 斷點模式下容易翻車的地方斷點最坑人的點是“忘了放行”。開了一堆自動斷點后你在頁面上點了十幾次刷新每次都停在斷點狀態(tài)然后你去看別的代碼幾分鐘后回來發(fā)現(xiàn) Fiddler 假死原因是會話積壓過多。解決方法是養(yǎng)成習(xí)慣用ShiftF11取消所有請求前斷點用AltF11取消所有響應(yīng)后斷點或者直接重啟 Fiddler。生產(chǎn)環(huán)境特別不建議開著全局斷點很容易把一個正常業(yè)務(wù)卡成“服務(wù)癱瘓”。我曾經(jīng)在聯(lián)調(diào)環(huán)境下忘記關(guān)閉響應(yīng)斷點導(dǎo)致整個測試團隊大面積超時自那以后我改完數(shù)據(jù)一定第一時間關(guān)掉 Breakpoint 開關(guān)。還有一點修改響應(yīng)體后Fiddler 會自動重新計算 Content-Length但如果你直接改的是壓縮后的響應(yīng)體例如 gzip修改內(nèi)容會亂碼。正確做法是先把響應(yīng)頭里的Content-Encoding: gzip移除讓 Fiddler 以明文處理修改完再按需重新壓縮。這個細節(jié)容易被忽視也是“我改了響應(yīng)怎么企業(yè)微信返回亂碼”的常見原因。5. 移動端與跨網(wǎng)絡(luò)抓包真機調(diào)試的那些配置細節(jié)5.1 同一局域網(wǎng)下的代理設(shè)置手機與電腦必須處于同一局域網(wǎng)并且電腦防火墻要允許 8888 端口對外監(jiān)聽。Fiddler 默認監(jiān)聽所有網(wǎng)絡(luò)接口但你需要在設(shè)置里確認“Allow remote computers to connect”是勾選狀態(tài)否則手機連代理會立刻失敗。電腦的局域網(wǎng) IP 獲取方式不同系統(tǒng)也有差異但核心是確保 IP 正確。在手機 Wi-Fi 設(shè)置里找到“代理”選擇手動填寫電腦 IP 和端口 8888。此時打開手機任意網(wǎng)頁電腦上應(yīng)該馬上出現(xiàn)新增會話。如果不出現(xiàn)用瀏覽器訪問代理 IP 和端口能打開 Fiddler 自帶的證書下載頁說明代理層通了打不開則多半是防火墻或局域網(wǎng)隔離策略攔截。5.2 不同手機系統(tǒng)的證書信任差異手機裝完根證書后“信任”這一步在兩類系統(tǒng)上思路不同。一類系統(tǒng)要求用戶在證書詳情里手動開啟高級信任開關(guān)另一類系統(tǒng)需要額外導(dǎo)入為系統(tǒng)級證書普通用戶模式導(dǎo)入的是用戶證書對部分 App 默認不受信。如果你只是調(diào)試瀏覽器流量用戶證書基本夠用但調(diào)試一些安全等級較高的 App你會發(fā)現(xiàn)請求直接報證書錯誤。遇到這種情況先別想歪路子。正確做法第一步是確認應(yīng)用是否允許用戶證書第二步是看應(yīng)用是否開啟代理檢測。很多 App 會對 HTTP 代理敏感檢測到系統(tǒng)代理后直接拒絕訪問。此時你可以嘗試改用透明代理或者把流量轉(zhuǎn)發(fā)到端口繞開系統(tǒng)代理檢測。但這些手段都只限于調(diào)試自己負責(zé)的應(yīng)用不能用來跳過別人服務(wù)的防護機制。最后不要為了方便而在生產(chǎn)環(huán)境長期關(guān)閉驗證。5.3 抓包工具連不上網(wǎng)常見原因排查順序手機連上 Fiddler 后發(fā)現(xiàn)所有請求都超時我按以下順序排查檢查 Fiddler 是否開啟“Allow remote computers”沒開的話手機代理直接被拒。電腦和手機 ping 一下同網(wǎng)段不通就移過去相連的網(wǎng)絡(luò)別在兩級路由器下折騰。關(guān)掉電腦上的殺毒軟件防火墻或者單獨放行 Fiddler 進程。在手機瀏覽器下載證書頁面能打開說明 HTTP 層通打不開說明代理被系統(tǒng)攔截。抓取 HTTPS 解密失敗時重新確認證書安裝與信任步驟。最容易被忽略的是電腦上有多個網(wǎng)絡(luò)適配器Fiddler 監(jiān)聽的是有線網(wǎng)卡的 IP而手機連接的是無線網(wǎng)卡的 IP兩者不在同一網(wǎng)段。你在命令行ipconfig看到的可能是無線 IP但 Fiddler 綁定的是有線。解決方式是直接給 Fiddler 監(jiān)聽地址綁定成0.0.0.0所有接口都監(jiān)聽手機配 IP 時用電腦當前連接路由的那個 IP。5.4 安全邊界只抓自己的設(shè)備流量抓包工具本身是中性技術(shù)就像一把螺絲刀可以用來修設(shè)備也可以用來拆設(shè)備。作為從業(yè)者我給自己立了三條規(guī)則第一只抓自己擁有或有明確授權(quán)的設(shè)備流量第二不把解密能力用于收集他人密碼、Cookie、賬號信息第三調(diào)試結(jié)束后及時移除代理配置和根證書尤其是公用電腦和公用測試機。這不僅是合規(guī)問題也是職業(yè)底線。公司里調(diào)試生產(chǎn)環(huán)境也要先確認是否有相關(guān)授權(quán)和監(jiān)控要求。Fiddler 的日志會保存所有流量包括明文密碼和 Token因此保存的 .saz 文件必須妥善處置不要隨手放到公開共享目錄。我記得有次一個同事把帶 token 的會話文件傳到了公共網(wǎng)盤結(jié)果第二天 token 被刷爆整個項目組加班換密鑰。這個教訓(xùn)值得每個用抓包工具的人記住。6. 從調(diào)試到自動化Composer、AutoResponder和腳本擴展6.1 Composer手工構(gòu)造請求當你已經(jīng)清楚一個接口所有參數(shù)后可以直接用 Composer 構(gòu)造請求而不必總是重復(fù)打開頁面觸發(fā)。把已有的請求拖進 Composer你可以改成別的 URL、改請求方法、改 header、改 body然后點 Execute 發(fā)送。這個能力在做接口回歸、給后端做冒煙測試時非常高效。需要注意的是 Composer 發(fā)送的請求默認會走當前代理也就是會出現(xiàn)在同一個會話列表里所以你能看到它的完整響應(yīng)。它還支持輸入原始 HTTP 報文很多人在做自定義協(xié)議調(diào)試時都是先把報文頭寫好再用 Composer 里的“Raw”標簽直接粘貼執(zhí)行。這里有個小技巧CtrlR切換 Inspectors 時Focus 在 Composer 的 URL 框可直接寫 URL回車就能發(fā)請求。6.2 AutoResponder實現(xiàn)“假接口”與Mock環(huán)境AutoResponder 是前端開發(fā)最愛的功能。它允許你把某個 URL 的響應(yīng)替換成本地文件、另一個 URL 或者一個自定義字符串。配置好后頁面請求到達 Fiddler 時不轉(zhuǎn)發(fā)到服務(wù)器而是直接返回你指定的內(nèi)容。用這個功能你可以在后端接口未完成時就完成前端聯(lián)調(diào)也可以把耗時接口臨時替換成固定返回讓測試環(huán)境擺脫依賴。我常用它造三種場景一是“先顯示 Loading再返回成功數(shù)據(jù)”二是“接口異常時返回 500 和錯誤提示”三是“圖片請求全部替換成本地占位圖”。每一種都只需要簡單的規(guī)則和文件路徑關(guān)鍵是把匹配規(guī)則寫準確。規(guī)則支持正則初學(xué)者可以用通配符比如regex:.*\.png$匹配所有 png 圖片。但要注意規(guī)則列表是有先后順序的越靠前優(yōu)先級越高。我踩過坑寫了一條/api/的規(guī)則結(jié)果把api/login和api/user全返回了同一個 JSON調(diào)試了好一會兒才發(fā)現(xiàn)是規(guī)則樹邏輯問題。6.3 FiddlerScript改動響應(yīng)的小玩法FiddlerScript 是 Fiddler 的腳本機制你可以把它理解成“插件鉤子”在事件函數(shù)里寫代碼對經(jīng)過的會話做自動化處理。雖然很多人覺得腳本有門檻但只要你會一點點函數(shù)規(guī)則就能做出很實用的工具。最經(jīng)典的例子是自動修改某個接口的響應(yīng) header在OnBeforeResponse函數(shù)里判斷 URL然后直接給 header 增加字段。我寫過一個小腳本專門給靜態(tài)資源加Cache-Control: no-cache避免開發(fā)時反復(fù)清緩存。還寫過在OnBeforeRequest里自動加Authorization頭的腳本省去每次手動填 Token 的麻煩。FiddlerScript 使用的是類似語法和事件模型初次上手不要求寫復(fù)雜邏輯從改一個 header 開始慢慢就能擴展成自己的調(diào)試助手。6.4 會話保存與回歸對比抓包不只是在出問題時用也應(yīng)該沉淀成團隊資產(chǎn)。Fiddler 可以把當前所有會話保存成 .saz 文件保存后重新打開會話列表、響應(yīng)內(nèi)容、時間戳全都保留。我習(xí)慣在項目每個版本發(fā)布前把關(guān)鍵流程抓一份 .saz 存到版本檔案里下次測試如果發(fā)現(xiàn)接口行為變了直接拿新舊兩份會話做對比立刻能看出是請求參數(shù)變了還是響應(yīng)結(jié)構(gòu)變了。對比時可以用 Fiddler 自帶的對比功能或?qū)С鑫谋竞笥脜f(xié)作工具比對。推薦先把感興趣的會話右鍵導(dǎo)出為文本再用文本對比工具查看差異。這個流程比口頭溝通“好像返回不一樣”可靠得多。另外保存會話時注意去掉安全性敏感字段如 Cookie、Authorization、Token 等可以用腳本在導(dǎo)出前清洗一遍。最后再分享一點個人經(jīng)驗抓包不是越全越好而是越“聚焦”越好。我在處理線上問題時第一步永遠是開host:過濾只保留目標域名第二步才開 HTTPS 解密第三步根據(jù)需求開斷點。這樣做能讓會話列表保持清爽不會在三千條請求里迷路。Fiddler 的快捷鍵和命令很多但你先記住CtrlX清空列表、CtrlF查找響應(yīng)內(nèi)容、AltF11取消斷點這三個足夠覆蓋 90% 的日常操作。工具終究是工具真正發(fā)揮價值的關(guān)鍵是你能不能把眼前這條流量理解成一條完整的業(yè)務(wù)故事。