兄弟們，咱們天天跟瀏覽器打交道，F12 可能比鍵盤上其他任何一個功能鍵按得都多。我們習慣了在 Network 面板里看著請求瀑布流，調試 API，分析性能。

但你有沒有停下來，哪怕一次，問過自己一個問題：這玩意兒到底是怎么做到的？

開發者工具（DevTools）明明只是瀏覽器的一個“面板”，它憑什么能像開了上帝視角一樣，攔截和監控瀏覽器內核發出的所有網絡請求？它和瀏覽器內核之間，到底藏著什么秘密通道？

今天，松哥就帶你把這個最熟悉又最陌生的功能給徹底扒個底朝天。搞懂了它，你不僅能理解 DevTools，更能瞬間想通 Playwright、Puppeteer 這類自動化工具的核心原理。

揭秘幕后大佬——CDP

答案其實很簡單，秘密通道的名字叫做 Chrome DevTools Protocol (CDP)。

你可以把 CDP 想象成一套瀏覽器內核（比如 Chromium）暴露出來的、功能極其強大的“調試 API”。而我們按 F12 打開的開發者工具，本質上就是 CDP 的第一個，也是最官方的一個客戶端應用。

它倆的關系，就像是：

• 瀏覽器內核：一個強大的“服務器”，默默地處理著渲染頁面、執行JS、發送請求等所有臟活累活。
• 開發者工具：一個“客戶端”，它通過 CDP 這條標準化的線路，向內核“服務器”發送指令（比如“給我所有網絡請求的詳細信息”）并接收內核推送的事件（比如“嘿，一個新的請求剛發生了！”）。

所以，你在 Network 面板看到的一切，都不是什么魔法，而是 DevTools 這個客戶端通過 CDP 協議，從瀏覽器內核那里“實時查詢”和“訂閱”來的數據。

從 DevTools 到 Playwright 的“權力交接”

好了，最關鍵的問題來了。既然 DevTools 可以通過 CDP 控制瀏覽器，那是不是意味著，任何程序只要學會了 CDP 這套“語言”，都能成為瀏覽器的“提線木偶師”？

Bingo！你答對了！

這正是 Playwright、Puppeteer、go-rod 等所有現代自動化工具的核心工作模式。它們本質上，就是更強大的、為自動化而生的“第三方 CDP 客戶端”。

現在，讓我們回到那個熟悉又強大的 API：Playwright.context.route()。

當你寫下這行代碼，試圖攔截某個請求時，Playwright 所做的事情，和 DevTools 在幕后的行為如出一轍，甚至更為深入。它利用了 CDP 中一個專門為此設計的“域”（Domain）—— Fetch 域。

整個攔截流程，就像一場精心策劃的“中間人干預”：

1. Playwright 下達“戒嚴令” (Fetch.enable)
   當你調用 context.route('**/*', ...)，Playwright 會通過 CDP 連接向瀏覽器發送一個指令：Fetch.enable。這等于告訴瀏覽器：“喂，老兄，從現在起，所有網絡請求你都別急著發，先暫停，等我通知?！?/p>

2. 瀏覽器“暫?！辈ⅰ吧蠄蟆?(Fetch.requestPaused)
   當頁面即將發出一個請求，瀏覽器會檢查并發現它處在“戒嚴”狀態。于是，瀏覽器會立即“凍結”這個請求，然后通過 CDP 發送一個 Fetch.requestPaused 事件給 Playwright，并附上請求的所有細節（URL, Headers, Body...）。

3. 你（通過 Playwright）做出“裁決”
   Playwright 收到這個事件后，將其封裝成我們熟悉的 route 對象，然后調用你寫的處理函數。此刻，你就是法官，可以決定這個請求的生死：

   • route.continue() (放行): Playwright 發送 Fetch.continueRequest 指令，瀏覽器接收后，將請求照常發出。
   • route.fulfill() (偽造): Playwright 發送 Fetch.fulfillRequest 指令，并把你提供的假數據一起給瀏覽器。瀏覽器根本不會發出真實請求，而是直接用你的數據“假裝”收到了一個響應。這對于 Mock 測試來說，簡直是神技！
   • route.abort() (掐死): Playwright 發送 Fetch.failRequest 指令，瀏覽器直接將這個請求作廢。

看明白了嗎？從 DevTools 的監控，到 Playwright 的攔截，它們共享著同一個技術基石——CDP。Playwright 的高明之處，在于把這些繁瑣的 CDP 指令交互和事件監聽，抽象成了一個極其干凈、直觀的 API。

我第一次想明白這個關聯時，有種豁然開朗的感覺。這正是優秀框架的價值所在：把復雜的協議細節留給自己，把簡單的編程體驗交給用戶。

CDP 就是終點嗎？不，大戲還在后頭

聊到這里，你可能會覺得 CDP 就是自動化領域的終極武器了。但從工程角度看，CDP 有一個致命的“原罪”：它是 Chrome 的“方言”，不是 W3C 的“普通話”。

這意味著，依賴 CDP 的腳本在跨瀏覽器（尤其是 Firefox, Safari）測試時，總會遇到各種兼容性問題。

因此，一個更宏大的敘事正在發生—— WebDriver BiDi (WebDriver Bidirectional) 的崛起。這是 W3C 聯合所有瀏覽器廠商共同推出的下一代自動化標準，旨在結合傳統 WebDriver 的跨瀏覽器優勢和 CDP 的強大雙向通信能力，成為真正的“世界語”。Playwright 和 Selenium 都在積極擁抱這個新標準。

總結

今天，我們從一個簡單的 F12 按鍵出發，揭開了它背后的秘密通道 CDP，然后發現這條通道不僅支撐著我們日常的調試工作，更是整個現代瀏覽器自動化生態系統的基石。

核心洞見是什么？

1. 萬變不離其宗：無論上層 API 設計得多么優雅（如 context.route），其底層能力都源于一個強大的協議（CDP）。理解這個協議，能讓你在面對各種工具時，瞬間看透本質。
2. 抽象的價值：我們應該感謝像 Playwright 這樣的框架。它讓我們不必去手動處理復雜的 CDP 事件和指令，而是聚焦于業務邏輯本身。這是軟件工程中“關注點分離”的完美體現。
3. 保持前瞻：技術永在演進。今天我們依賴 CDP，但明天 WebDriver BiDi 可能會成為新的主流。理解技術演進的“為什么”，比單純記住一個 API 更重要。

所以，下次當你再次按下 F12，看著網絡請求列表時，希望你能想起它背后的 CDP。而當你寫下 await route.fulfill() 時，更能會心一笑，因為你清楚地知道，在這行代碼背后，一場瀏覽器、CDP 和 Playwright 之間的精彩對話正在上演。

?轉自https://www.cnblogs.com/aisong/p/18922518