什么是 Puppeteer？Chrome 和 Firefox 自动化解释

Scrapeless Scraping Browser 提供受管理的云浏览器会话，Puppeteer 客户端可以用于浏览器自动化和动态网络数据工作流程。

Puppeteer 赋予 JavaScript 对浏览器的直接控制

Puppeteer 是一个开源的 JavaScript 库，用于通过高级 API 控制受支持的浏览器。它暴露浏览器、上下文、页面、框架、输入、网络、跟踪、截图、PDF 和评估操作。脚本可以启动一个 Puppeteer 管理的浏览器，或连接到一个现有的兼容浏览器进程。由于该 API 以 JavaScript 为优先，并且与浏览器概念紧密映射，它适合 Node.js 服务、命令行工具、爬虫、视觉捕捉系统和自定义测试框架。

官方 Puppeteer 介绍 将 Puppeteer 作为一个用于 Chrome 和 Firefox 自动化的 JavaScript 库。较早的描述常常将 Puppeteer 简化为无头 Chromium，但现在已经不完整。无头 Chrome 仍然是一个核心用例，但当前浏览器支持和协议工作包括 Firefox。团队在选择浏览器或设计迁移时，应使用当前的兼容性表，而不是重复历史定义。

浏览器、上下文、页面和协议协同工作

Browser 对象拥有进程或远程连接。BrowserContext 将 Cookie 和存储分开以便独立会话。页面表示标签页，并提供导航、DOM 查询、定位器、事件、截图和脚本执行。在高级 API 之下，协议传输命令和事件。Chrome 自动化通常使用 CDP，而 WebDriver BiDi 提供一个跨浏览器的事件驱动路径，Puppeteer 用于 Firefox，并且可以在支持功能的情况下与 Chrome 一起使用。

官方 Puppeteer WebDriver BiDi 指南 解释了 Puppeteer 的 WebDriver BiDi 支持，并指出不支持的操作可能会产生 UnsupportedOperation 错误。该边界在协议选择中很重要：CDP 公开了深度的 Chrome 特定表面，而 BiDi 的目标是标准化的跨浏览器控制，但仍在开发中。测试确切的特性——网络拦截、下载、仿真、跟踪、扩展或浏览器管理——在项目所需的协议和浏览器上。

• 浏览器。 启动或连接到浏览器进程，并管理整体生命周期。
• BrowserContext。 在浏览器内部创建隔离的 Cookie、缓存和存储边界。
• 页面。 表示标签页，并暴露导航、输入、评估、网络和捕获操作。
• CDP 会话。 当高级 API 不够时，提供对 Chrome DevTools 协议域的更低级访问。
• WebDriver BiDi 连接。 为受支持的跨浏览器操作提供事件驱动的标准路径。

Puppeteer 可以启动、安装或连接

完整的 Puppeteer 包通常管理兼容的浏览器下载，这使得本地项目易于启动，但增加了安装大小。Puppeteer Core 省略了该管理的浏览器，并在浏览器可执行文件或远程服务单独提供时有用。远程连接保持 Node.js 控制进程本地，同时浏览器执行发生在另一台主机上。每种方法都会改变谁拥有浏览器版本、可执行路径、沙盒设置、操作系统依赖关系和清理。

官方 Puppeteer 支持的浏览器表 发布 Puppeteer 发布版本与支持的 Chrome 和 Firefox 版本之间的映射。该映射是操作性的，而非琐事。固定包而默默地更改浏览器可能会创建不支持的组合，而升级包可能会更改下载的浏览器。容器和 CI 镜像应记录双方信息。远程服务应公开足够的环境信息，以重现在生产中观察到的行为。

Puppeteer 选择影响所有权和可移植性

相同的页面 API 可以位于不同的安装和协议模型之上，但这些模型并不具有相同的维护或功能边界。

受益于集中API的Puppeteer用例

Puppeteer适合希望在JavaScript应用程序中使用浏览器原语，而不使用规定测试架构的项目。

Puppeteer将测试架构和容量留给项目

Puppeteer不规定一个运行器、断言库、固定模型或报告格式。这对于在应用程序中嵌入自动化是有用的，但测试团队必须组装和维护这些层次。浏览器进程也消耗物质资源，并且一个Node.js进程可以在代码看起来复杂之前创建太多页面。仔细定义浏览器和上下文池，确定性地关闭资源，并隔离不应共享存储的账户或市场。

Chrome开发工具协议文档 文档Chrome开发工具协议作为用于仪器操作、检查、调试和分析Chrome的接口。CDP的深度是有价值的，但Chrome特定的命令降低了可移植性。在一个小适配器后保持低级协议调用，记录他们为何需要，并在同一工作流程通过WebDriver BiDi或其他浏览器运行时提供清晰的行为。

Puppeteer项目准备清单

重要的决定是浏览器所有权、协议、上下文范围、证据和Puppeteer有意保持开放的框架层。

1. 从需求中选择浏览器。 确认Chrome是否足够，或者Firefox行为是否重要。使用当前的支持浏览器表并在提交矩阵之前运行确切的组合。
2. 选择包的所有权。 当Puppeteer应该管理一个兼容的浏览器时使用完整包，或者当容器、系统包或远程服务拥有浏览器时使用Puppeteer Core。
3. 识别协议依赖。 列出每个直接的CDP调用和预计通过WebDriver BiDi每个特性。保持浏览器特定行为可见，而不是隐藏在通用帮助器中。
4. 有意地范围上下文。 对于独立的Cookies和存储使用单独的上下文。只有在工作流程意图继续一个身份或状态时，共享上下文才是合适的。
5. 等待有意义的条件。 将进展绑定到选择器、响应、URL变更、函数结果或其他可观察状态。固定延迟不应承担主要的同步负担。
6. 组装测试堆栈。 如果项目是测试套件，请命名围绕Puppeteer的运行器、断言库、固定、报告和文档政策。
7. 测量浏览器容量。 在增加工作者之前，跟踪进程内存、活动页面、启动成本、会话持续时间、网络量和目标主机并发性。
8. 验证输出内容。 检查最终的URLs、预期字段、页面语言、记录数量和页面类型。成功的导航仍可能落在同意屏幕或不完整的应用程序外壳上。

与无抓取抓取浏览器一起使用Puppeteer

无抓取抓取浏览器可以托管一个浏览器会话，Puppeteer客户端通过支持的远程端点连接到该会话。该应用程序保持熟悉的Puppeteer页面操作，而无抓取则拥有云浏览器进程、会话设置和配置的网络路径。

在移动生产工作流程之前，验证当前的端点、支持的客户端包、会话控制和远程特性表面。回顾当前 无抓取抓取浏览器产品概述, 无抓取抓取浏览器入门文档,和 无抓取定价 在选择运营模式之前。

结论：Puppeteer是一个专注的浏览器控制库

Puppeteer 为 JavaScript 应用程序提供了一种直接的、高级的方式来控制 Chrome 和 Firefox。它可以启动兼容的浏览器，连接到远程会话，通过 CDP 工作，并使用 WebDriver BiDi 进行支持的跨浏览器操作。专注的 API 使得将浏览器行为嵌入自定义系统变得简单。

这种专注也将重要决策留给项目。控制浏览器版本，使协议假设明确，隔离上下文状态，选择基于条件的等待，验证返回的页面，并在测试时组装测试堆栈。