Playwright vs. Selenium：2026 架构评审

I’m ready to translate the article for you, but I need the full text you’d like translated. Could you please paste the content (excluding the source line you already provided) here? Once I have the article’s body, I’ll translate it into Simplified Chinese while preserving all formatting, markdown, and code blocks.

介绍：超越 API 表层

到 2026 年，Playwright 与 Selenium 之间的争论已基本超出“语法偏好”或“语言支持”。对于高级自动化架构师而言，选择不再是你更喜欢 driver.find_element 还是 page.locator；而是一个关于 基础设施拓扑 与 协议效率 的根本决策。

历史上，浏览器自动化被视为“脚本化”：发送点击按钮的指令并等待结果。如今，它已成为 分布式基础设施 的关键层。我们在瞬时容器中运行测试，在强大的 WAF 之后抓取数据，并自动化受硬件绑定凭证保护的复杂认证。在这种高风险环境下，自动化工具的底层架构决定了其 可靠性、速度和可维护性。

本评测将拆解 Selenium（包括 W3C WebDriver BiDi 演进）的内部机制以及 Playwright。我们将分析为何 2004 年做出的架构决策至今仍限制 Selenium，并阐明 Playwright 的 “headless‑first” 事件循环如何契合现代 Web 的实际情况。

两者之间最具决定性的单一差异是用于驱动浏览器的 通信协议。这不是实现细节；它是导致两者在性能和稳定性上几乎所有差异的根本原因。

Selenium的架构

Selenium 基于 WebDriver W3C 标准 构建，根本上是一种 RESTful HTTP 协议。Selenium 脚本中的每一次操作都会触发一个独立的 HTTP 请求：

Client → POST /session/{id}/element          (Find element)
Driver → receives request, translates to browser internal command,
          waits for browser, returns JSON response
Client ← parses JSON

Client → POST /session/{id}/element/{id}/click (Click element)
Driver → receives request, executes click, returns JSON
Client ← parses JSON

后果

• 通信频繁 → 引入 控制循环延迟。
• 每条指令都会产生网络开销、序列化和反序列化。
• 在本地环境下，这种延迟可以忽略不计（毫秒级）。
• 在分布式网格（例如 Sauce Labs、BrowserStack、CI 运行器）中，往返时间会累积，形成一种“停‑走”执行节奏，导致整体速度更慢且更容易出现竞争条件。

Playwright的架构

Playwright 放弃了标准的 HTTP，改用 单一、持久的 WebSocket 连接（利用 Chrome DevTools Protocol – CDP，或 Firefox/WebKit 的等价协议）。连接建立后，通道保持打开状态。

关键特性

Auto‑Wait 与 Explicit Wait

高级工程师经常将 Playwright 的 Auto‑Wait 视为关键特性。了解其架构实现可以解释为什么 Selenium 即使使用 “Explicit Wait” 也难以复现该功能。

Selenium（Explicit Wait）

• 等待逻辑位于客户端脚本（Python/Java/C#）中。
• 脚本通过 HTTP 请求反复轮询浏览器驱动：

"Is it visible? No. (Wait 500 ms). Is it visible? No. (Wait 500 ms). Is it visible? Yes."

• 这会产生网络噪声，并产生 竞争条件窗口——元素可能在轮询间隔之间短暂出现又消失，导致测试不稳定。

Playwright（Auto‑Wait）

• Playwright 将定位器逻辑编译后直接注入浏览器上下文，通过 CDP 会话执行。
• “等待”发生在 浏览器自身的事件循环 中（与 requestAnimationFrame 和绘制周期保持同步）。
• 它在同一渲染循环中检查元素的稳定性（边界框移动）和可操作性（z‑index 覆盖）。
• “点击”命令仅在浏览器确认元素已准备好时才执行——一次原子化的 Check‑and‑Act，消除了外部轮询固有的竞争条件。

网络控制

在 2026 年，自动化很少仅止步于点击按钮。它通常需要 模拟 API 响应、注入请求头以及拦截分析追踪器。

Selenium

• 过去需要使用 中间人 (Man‑in‑the‑Middle, MITM) 代理（例如 BrowserMob）来拦截网络流量。
• 缺点：证书信任问题、吞吐量下降、基础设施复杂。
• Selenium 4+ 引入了 NetworkInterceptor，但它是 基于 WebDriver 协议的补丁式实现——粒度有限，且在不同浏览器之间容易出现兼容性问题。

Playwright

• 通过其基于 CDP 的架构 免费获得网络控制。
• 位于浏览器的网络栈与渲染引擎之间，能够原生地暂停、修改或中止请求 无需代理服务器。

好处

• 零延迟模拟 – 请求从不离开浏览器进程。
• 可靠性 – 主机机器上无需安装 SSL 证书。
• 粒度 – 路由逻辑（全局模式、正则表达式）即时评估。

WebDriver BiDi 的现实

Selenium 5 已经全面采用 WebDriver BiDi，这是一项标准化的努力，旨在将双向通信（WebSockets）引入 WebDriver 标准。这是 Selenium 对 Playwright 的回应。

Playwright 的优势

• 在 单页应用（SPA） 革命之后，Playwright 的 Browser Context 模型——允许在单个浏览器进程中拥有数百个隔离的、类似隐身模式的配置文件——在架构上超越了 Selenium 的 “One Driver = One Browser” 模型。
• 这使得在容器化环境（Kubernetes/Docker）中大规模运行 Playwright 成本呈指数级降低。

何时坚持使用 Selenium，何时采用 Playwright？

Selenium（带 BiDi） vs. Playwright

何时坚持使用 Selenium

• 您需要测试 旧版浏览器（例如 IE 11）或特定的旧版 Chrome/Firefox 版本。
• 您的自动化 深度集成 Appium 用于原生移动端测试。
• 您的团队主要使用 Java 或 C#，并偏好 同步、阻塞式 API 风格。

何时迁移到 Playwright

• 您在测试 现代单页应用（React、Vue、Angular），其中组件重新渲染导致 Selenium 不稳定。
• 您需要 高性能爬取或数据提取（网络拦截至关重要）。
• 您希望通过使用浏览器 上下文 而非独立进程，将 CI/CD 基础设施成本降低 30‑50 %。

TL;DR (2026)

Playwright 不再仅仅是“更好的 Selenium”。
通过与浏览器通过 WebSocket 紧密耦合，它消除了导致十年不稳定测试的抽象层。

• Selenium 仍然是 互操作性的巨头 和 标准合规性 的代表；其基于 W3C WebDriver 的基础保证它可以在任何地方、永远运行。
• Playwright 提供了一种 不同类型的工具——其架构在协议层面解决同步和延迟问题，让你专注于测试逻辑，而不是睡眠语句。

对于构建 可靠、高速的现代 Web 应用自动化流水线 的团队来说，Playwright 提供了最小阻力的路径。