Playwright 与 Puppeteer 与 Selenium：框架比较

编程语言支持

Selenium 是为广大的开发者群体设计的，这就是为什么它拥有最广泛的官方语言支持。Java、Python、C#、Ruby、JavaScript、Kotlin、PHP 以及其他编程语言都有官方库。多年的发展使 Selenium 成为几乎是一个通用的工具。

Puppeteer 最初是专门为 Node.js（JavaScript 和 TypeScript）开发的。官方上，仅支持这些环境，尽管有非官方的 Python、.NET 等端口。尽管如此，Puppeteer 主要和最新的接口仍然是 JavaScript。

Playwright 开箱即支持多种语言。除 JavaScript 和 TypeScript 外，还有 官方客户端 支持 Python、Java 和 .NET（C#）。与 Puppeteer 不同，Playwright 不仅限于 Node.js——您可以使用任何官方支持的语言编写脚本。

因此，从编程语言多样性来看，Selenium 和 Playwright 占优势。Selenium 拥有最广泛的官方支持，包括稀有和遗留语言。Playwright 支持最受欢迎的现代语言。Puppeteer 官方仅限于 Node.js 生态系统。

浏览器支持

Selenium 基于 WebDriver 标准，可以自动化几乎所有带有兼容驱动的浏览器。支持 Chrome（Chromium）、Firefox、Safari、Edge、Opera，甚至还有 Internet Explorer。在跨浏览器覆盖率方面，Selenium 提供了最广泛的支持。即使 Internet Explorer 的自动化似乎过时了，但在某些环境中，遗留系统支持可能是决定性的。

Puppeteer 专注于 基于 Chromium 的浏览器。开箱即用，与 Google Chrome（Chromium）和其他基于 Chromium 的浏览器兼容。对其他引擎的支持有限：如果您需要 WebKit 或非 Chromium 浏览器，Puppeteer 不能直接帮助您。

Playwright 被设计为一种多浏览器解决方案。支持三个主要引擎：Chromium、Firefox 和 WebKit。它不适用于遗留或罕见的浏览器，但对于大多数抓取和测试任务，这种覆盖范围已经足够。

在跨浏览器能力方面，Selenium 仍然是领导者，其次是覆盖所有现代引擎的 Playwright。在这方面，Puppeteer 的限制更大。

功能性和易用性

这三种解决方案都提供了一套核心的浏览器自动化功能：

• 启动浏览器（包括无头模式）；

• 页面导航；

• 元素选择；

• 用户互动模拟（点击，文本输入）；

• JavaScript 执行；

• DOM 提取，等等。

任何标准的 网页自动化 任务都可以用 Selenium、Puppeteer 或 Playwright 解决。然而，它们在开发者便利性和内置功能方面有所不同。

Selenium 通过 WebDriver API 提供低级控制。与现代工具相比，其语法和方法可能显得过于冗长和模板繁重。开发人员往往需要配置显式等待，并详细描述每个动作。然而，多年来 Selenium 已经变得非常稳定。强大的包装库（如 WebDriverIO 或 Selenide）部分简化了开发。Selenium 本身是相当简约的。

更新的 Puppeteer 和 Playwright 提供了更简洁、现代的 API。两者都异步操作，简化了逐步场景的编写，避免了深层嵌套的回调。

Playwright 特别强调开发者体验。它包括内置工具，可以简化测试和脚本的编写：Playwright Inspector 允许实时分步调试，而 Codegen 则记录您在浏览器中的操作并自动生成相应的代码。

这大大降低了初学者的入门障碍。Playwright 还默认实现了智能自动等待，而无需显式添加等待语句。结果是代码更简洁，错误更少。

Codegen 让您可以完成浏览器操作并生成相应的代码

Puppeteer 并没有提供同等程度的自动等待。与 Selenium 一样，同步责任在于开发者（或外部实用程序）。Puppeteer 和 Selenium 也缺乏内置的代码生成或交互模式。

Puppeteer 的一个强项是其与 Chrome DevTools 的深度集成。它通过 DevTools 协议直接控制浏览器，提供访问低级操作的能力，例如：

• 拦截网络请求和响应；

• 监听浏览器控制台事件；

• 欺骗地理位置并模拟移动设备；

• 检索性能指标。

Playwright 也提供类似的功能（通过 Chromium 协议及其自身对其他引擎的实现）。在 Playwright 中，请求拦截和移动仿真也很方便。

模拟移动设备

Selenium 最初并不是为了这种深层次控制而设计的。在第 4 版中才出现了有限的 DevTools 支持。因此，对于涉及网络请求或高级浏览器特性的任务，Puppeteer 或 Playwright 通常比纯粹的 Selenium 更可取。

就处理动态和 JavaScript 密集型网站而言，所有这三种工具都能启动真实浏览器并在页面上执行 JavaScript，这使它们适合抓取 SPAs、动态加载的网站和类似情况。然而，它们在这类任务中的效率有所不同：

• Selenium 在这些条件下效率较低：在重度 JavaScript 负载下，脚本运行速度较慢，并且每个会话占用更多资源。

• Puppeteer 由于与 Chrome 引擎的紧密集成，在处理重 JavaScript 任务时表现良好，使其成为在 Node.js 环境中进行快速自动化的最佳解决方案之一。

• Playwright 除了高速外，还提供跨不同浏览器引擎（Chromium、Firefox、WebKit）的高级负载分配。当需要并行渲染重页面时，这非常方便。

Playwright 因其周到的设计和开发者便利性而脱颖而出：Inspector、自动代码生成、自动等待和其他细节都赋予其优势。Puppeteer 在 Node.js 环境中提供简单快速的用法。尽管 Selenium 在某些场景中较慢，但它非常可靠。Puppeteer 或 Selenium 中没有真正独特的功能，几乎所有内容都可以在这些框架中的任意一个中实现。因此，就可用性和功能而言，Playwright 可被视为赢家（特别是对初学者而言）。

Playwright 让您逐帧分析测试执行，查看网络请求，并在任何时候检查 DOM 状态

性能和速度

如前所述，Selenium 比 Puppeteer 和 Playwright 慢。这是有合理解释的，因为 Selenium 通过较重的 WebDriver 协议（HTTP 请求）与浏览器通信，而 Puppeteer 和 Playwright 使用的是更轻量的 DevTools 连接（WebSocket）。在实践中，这一点得以证实：Puppeteer 和 Playwright 执行场景的速度比用 Selenium 编写的等效脚本快（有时可快一倍）。例如，相同的场景（抓取预订页面）使用相同的输入数据显示出 Selenium 的性能比 Playwright 低。在 24 小时的操作中，用 Playwright 构建的抓取器处理了 30,000 个 URL，而 Selenium 在峰值时最多处理了 8,000 个。

Puppeteer 和 Playwright 之间还有一个细微的差异：在非常短的脚本中，Puppeteer 有时比 Playwright 表现更好。这是由于 Playwright 的初始开销较高所致。然而，在长时间运行的任务中，这个差异趋于平缓：在扩展会话期间，Puppeteer 和 Playwright 的速度几乎相同。因此，仅基于速度做出选择并不重要，除非您需要执行数千个非常短的会话，在这种情况下，Puppeteer 的浏览器启动时间可能更快。

不仅 Selenium 较慢，它在硬件方面的要求也更高。这个框架消耗更多的 RAM，并对 CPU 施加更大的负载。当并行运行数 十个浏览器线程时，资源使用的差异会变得显而易见。

同时，重要的是保持客观并考虑：

1. 外部因素：网络延迟、网站加载速度和服务器端执行时间通常比框架本身的 100 毫秒差异更重要。

2. 项目规模：对于小项目，速度差异可能微不足道。Selenium 仍然是一个可行的工具；只是需要更多资源才能在大规模时获得相同成果。

与 Selenium 相比，Puppeteer 和 Playwright 的速度更快，并且它们在性能上基本上是可以互相比较的，尽管在短期任务中 Puppeteer 可以稍快些。如果您的目标是获得最大性能，并且您仅限于 Chrome，那么 Puppeteer 可能更高效。然而，在其他情况下，考虑到框架之间的其他差异，速度不太可能成为决定性因素。

扩展和并行执行

既然我们已经讨论过并行执行，就让我们更仔细地看看。在抓取时，同时运行多个浏览器会话是必须的功能。它用于加速测试或同时抓取多个页面。然而，重要的是要了解并发通常受限于资源（CPU/RAM）、网络容量和目标网站的限制，而不仅仅是选择的解决方案。这里的实现方法也有不同之处：

• Selenium 提供了一个专用解决方案——Selenium Grid。这是一个独立组件，允许在不同机器或浏览器上分布式测试执行。Grid 功能强大但相当复杂，需要设置基础设施（主机、节点、中心等）。在网络抓取中用得较少，但有助于水平扩展 Selenium。也有较轻的替代方案（例如 Selenoid）用于本地并行浏览器执行。Selenium 本身不包含内置的 API 并行编排系统——通常通过自己的代码级别或通过 Grid（或类似工具）实现并行执行，当需要跨机器进行分布时使用。

• Puppeteer 本身并不提供内置的集群管理解决方案，但可以手动并行启动多个实例。还有一个流行的开源库 puppeteer-cluster 可以简化并行运行多个 Chromium 实例及其间任务分配，但这仍然是一个外部工具。Puppeteer 本身无法开箱即用地协调多个浏览器——您将需要编写自定义代码或使用其他库。在实践中，Puppeteer 最常用于与 Chromium 基于的浏览器配合使用，因此如果您需要不同的引擎和/或浏览器，框架的灵活性会更有限。

• Playwright 最初设计时就考虑到并行执行。在使用内置的 Playwright Test Runner 时，测试默认会在多个线程中自动执行。即使没有使用 Test Runner，Playwright API 也允许您在单个进程中打开多个独立的浏览器上下文——类似于从一个代码库管理多个隔离的浏览器配置文件。此外，Playwright 还支持将测试分布到不同机器上，这简化了大任务量的扩展。

因此，Playwright 在三个解决方案中提供了最好的开箱即用并发支持。其次是 Selenium，而 Puppeteer 则排第三。然而，这种比较适用于它们的基本配置。在大型真实世界系统中，周围的基础设施、任务队列、稳定性和硬件资源更重要。

对于大规模网络抓取，Selenium 通常不太合适，因为它相对较慢且资源密集，这可能成为瓶颈。Puppeteer 比较快，但限于一个浏览器引擎（Chrome）。当在相同引擎和具有相同签名类型下执行大量任务时，可能会出现额外的限制。Playwright 则允许将负载分配到不同浏览器和线程中。然而，总体效率始终受到 CPU/RAM、网络带宽和目标网站限制的限制。

隐蔽和反检测

在抓取网站时，不仅速度和加载性能重要，解决方案是否对反机器人系统可检测也同样重要。现代网站可以通过各种技术信号识别自动化客户端——遗憾的是，所有这三个框架默认都留下了自动化痕迹。

Selenium、Puppeteer 和 Playwright 最初都是为白帽目的（如测试、监控）创建的，而不是为了伪装成真实的浏览器。因此，它们发送的信号明确表明了自动化，反机器人系统会在检测机器人时考虑这些信号。

最明显的模式是特殊的标志 navigator.webdriver = true。在某些自动化配置中，此属性会暴露出来，是“受控”浏览器的快速指示器。这是页面脚本可用来怀疑自动化的一个开放信号。确切的行为取决于引擎、模式和启动方法，因此仅依赖单个信号是不够的。

反机器人脚本也检查其他指标：不匹配的Canvas 或 WebGL 指纹、缺失的插件、navigator.languages 或 deviceMemory 中不寻常的值，等等。

问题是通过特殊补丁和浏览器包装来解决的，试图将自动化伪装成人工用户行为。例如，Puppeteer 有 puppeteer-extra-plugin-stealth 插件，当启动 Chromium 时：

1. 禁用某些标志（包括 --disable-blink-features=AutomationControlled，移除 navigator.webdriver）；

2. 用更真实的值重写多个 JavaScript API 函数；

3. 修复已知的指纹异常。

类似的方法适用于 Playwright——有第三方模块，如 playwright-stealth，复制 puppeteer-stealth 的启发式。Playwright 允许您在创建新页面时执行代码，这使得可以在网站加载前重写 navigator.webdriver 或其他属性。

对于 Selenium，可使用 Undetected Chromedriver 模块。它通过移除自动化签名来修改标准的 ChromeDriver。例如，它处理 AutomationControlled，隐藏“Chrome 正由自动化测试软件控制”的信息，等等。

然而，重要的是要了解完全隐藏机器人模拟非常困难。考虑一下反检测浏览器 Octo Browser：它允许您配置唯一的 指纹（Canvas、WebGL、字体、音频），模拟人类输入模式，隔离会话，等等。而 Puppeteer 或 Playwright 即使有插件，也仅涵盖基本的欺骗技术，并只能绕过最简单的保护系统。因此，如果您的目标是严肃地挑战反机器人系统，则需要进行额外的配置：

• 在非无头模式下运行浏览器；

• 随机化用户代理、时区和 WebGL 指纹；

• 使用隐蔽类型的插件。

这虽然仍不足以对抗高级系统，但可以帮助绕过基本的反机器人保护。

因此，就隐蔽性而言，这三个框架中没有一个有明显优势。

在抓取和测试中的使用：选择哪个框架

每个工具都有自己的优势，选择取决于您的任务和限制。

• 如果您是初学者开发者，请考虑选择 Playwright。它提供了更简单的开始方法，使您更容易从头开始取得成果。开箱即用，Playwright 可以为您处理大部分日常工作，降低了入门门槛。

• 如果您的项目已经使用 Selenium 或需要与现有的测试基础设施集成，选用 Selenium 是有意义的。大公司通常已经建立起围绕它的生态系统。当需要支持奇怪的组合（例如，在 Microsoft Edge IE 模式中测试遗留站点或用 Ruby 或 PHP 编写脚本）时，Selenium 也是不可或缺的。对于遗留系统，它仍然是一个可靠的工作马。

• 如果您的主要场景是网络抓取，自动化是在云中部署的，而速度和可扩展性很重要，请考虑选择 Playwright。它是一种快速且现代的工具，更易于扩展。Playwright 还积极引入新功能，这使其在未来很有前途。

• 如果您只需要自动化 Chrome（Chromium）并需要最大速度和低级控制，请选用 Puppeteer。对于不需要 Beyond Chrome 的 Node.js 项目来说，它是理想的。在这种狭窄的使用场景中，它在原始性能上稍超越其他竞争者。Puppeteer 还提供对大多数 Chrome DevTools 功能的直接访问，这在需要 PDF 页面的快照或深入调试浏览器事件时尤其重要。

• 对于自动化测试（QA），选择就不那么明显了。如果您正在开始一个新的测试项目并使用现代技术栈，Playwright 可以显著提高生产力。然而，在许多企业中，Selenium 仍然是标准。还有一个替代方案是 Cypress（用于 Web 应用程序），但这又是一个单独的话题。在三个讨论的工具中，Selenium 在复杂集成和长期项目中仍然是一个可靠的选择，而 Playwright 非常适合快速启动和现代 Web 技术，Puppeteer 则适合专门的 Chrome-only 场景。

如您所见，这里没有明确的赢家，因为每种解决方案在其自身的领域都很强。然而，Playwright 可以被视为一个平衡的选择，前景广阔：它结合了广泛的功能和高速度，是新项目的强劲候选者。Selenium 仍然适用于其语言和浏览器兼容性的独特组合以及长期以来建立的可靠性。Puppeteer 则是一个优秀的工具，尤其是在您深深嵌入 Node.js 生态系统并重视简单性和直接控制的情况下——在那个领域，它是难以击败的。

最终，在选择框架时，要专注于项目的具体需求：所需的浏览器、编程语言、规模、反检测的重要性等等。所有三种解决方案都在积极发展，并能够处理复杂的浏览器自动化任务。选择正确的工具是高效开发和成功项目部署的关键。