楔子
在自動化測試與爬蟲的世界裡，Playwright 憑藉著強大的選取器（Selectors）與跨瀏覽器支援，早已成為開發者的心頭好。然而，當我們跳出官方支援的 TypeScript/Node.js、Python、Java 與 .NET，來到 Dart、Rust 或 Go 的領域時，你會發現一片荒蕪。
許多開發者在 GitHub Issue 敲碗希望官方增加支援，或試圖自己動手寫一個 Binding。但在你動手之前，如果翻開 Playwright Python 的原始碼，你會發現一個真相：在 Python 的外殼底下，竟然偷偷跑著一個 Node.js。
本文將帶你拆解 Playwright 的工程本質，探討為什麼「不寫 Binding」才是真實世界中最理智的工程決策。
揭開真相：那個「掛羊頭賣狗肉」的 Python Binding
如果你去研究 Playwright Python 的實作細節，你會發現它並不是透過 FFI（Foreign Function Interface）直接呼叫 C++ 底層驅動，而是在執行一個完整的 Playwright Driver，其本質就是一個 Node.js 環境。
def compute_driver_executable() -> Tuple[str, str]:
driver_path = Path(inspect.getfile(playwright)).parent / "driver"
cli_path = str(driver_path / "package" / "cli.js")
if sys.platform == "win32":
return (
os.getenv("PLAYWRIGHT_NODEJS_PATH", str(driver_path / "node.exe")),
cli_path,
)
return (os.getenv("PLAYWRIGHT_NODEJS_PATH", str(driver_path / "node")), cli_path)當你呼叫 page.click() 時，幕後的流程是這樣的：
- Python 端：將操作指令序列化成 JSON。
- 傳輸層：透過
stdin/stdout管道（Pipe）將指令丟給底層的 Node.js 子進程。 - Node.js 端（核心）：真正執行 Playwright 的核心邏輯，操作瀏覽器。
- 回傳：Node.js 執行完後，再將結果透過 JSON 傳回 Python。
這不是我們想像中優雅的編譯級 Binding，這是一個標準的 RPC（Remote Procedure Call）架構。
為什麼微軟不理會「增加 Binding」的請求？
既然是用 RPC，多包幾個語言的 Proxy 不就好了嗎？但在真實工程中，這是一筆極高的維護債務。
核心邏輯過重
Playwright 的核心（Browser 調度、網路攔截、Locator 邏輯）極其複雜且更新頻繁。如果要為每個語言開發「純血」的 Binding，意味著微軟必須在每個語言中重寫一遍這些邏輯，這在商業上完全不划算。
Protocol Drift（協議漂移）
Playwright 的內部 RPC 協議並不是像 W3C WebDriver 那樣的國際標準，它是私有且不穩定的。官方團隊為了迭代速度，隨時可能修改 JSON 結構。 如果公開了 Binding Guide 或支援了 10 種語言，每當核心引擎一改，10 個語言的維護者都要同步更新、編譯、發布，這會演變成一場版本控管的災難。
Proxy Trap（代理陷阱）
對開發者而言，多一個 Binding 只是多了一個 Proxy。既然底層非得跑 Node.js 不可，那麼多套一層 Dart 或 Rust 的皮，除了滿足「語法統一」的快感外，還引入了額外的序列化損耗與 debug 難度。
真實工程觀：別再做 Binding，擁抱 Sidecar
在教科書式的開發思維中，我們追求 100% 的語言純度；但在資深工程師眼裡，我們追求的是 ROI（投資報酬率） 與 系統解耦。
當你發現 Playwright 沒有你所用語言的官方 Binding 時，最好的做法不是去自造輪子，而是採用 Sidecar（邊車）模式 或 Microservice（微服務）：
- 隔離黑箱：寫一個極簡的 Node.js 腳本，負責所有的 Playwright 操作。
- 定義 API 邊界：透過 HTTP、WebSocket 或標準 I/O 與你的主程式（例如 Dart、Go）溝通。
- 利用生態系：在 Node.js 端，你可以直接使用
npm上豐富的插件（如隱身模式、驗證碼破解），而不需要痛苦地在主程式側重寫封裝。 - 穩定維護：官方更新了？你只需要升級 Node.js 端的
playwright套件，主程式的通訊邏輯完全不需要更動。
結語：會心一笑後的工程抉擇
當我在 Playwright Python Repo 看到 Node.js 路徑的那一刻，我笑了。那個笑聲代表著對現實工程妥協的認同——即使是微軟，也會在「跨語言支援」與「維護成本」之間選擇最務實的路。
如果你也在考慮為某個語言寫 Playwright Binding，請先問問自己：我是想解決問題，還是想滿足語言潔癖？
在大多數情況下，寫一個 Sidecar CLI 只需要兩小時，而寫一個註定會過期的 Binding 卻要花上半年。看透技術底層的「不優雅」，並選擇最高效的解決方案，才是邁向實務的必經之路。