常见问题

Chrome Browser Automation 团队维护这个库，不过我们也很欢迎你的帮助与专业经验！见贡献指南。

从 Puppeteer v23.0.0 起，Puppeteer 同时支持 Chrome 与 Firefox。

自动化 Chrome 时，Puppeteer 默认使用 Chrome DevTools Protocol（CDP），但也可以用 WebDriver BiDi 来驱动；自动化 Firefox 时默认使用 WebDriver BiDi。API 支持上的细微差异，见 WebDriver BiDi 指南。

从 Puppeteer v23.0.0 起，Puppeteer 对 WebDriver BiDi 的支持已可用于生产，可驱动 Chrome 与 Firefox。

会。尽管 Puppeteer 已经支持 WebDriver BiDi，我们并不会停止用 CDP 自动化 Chrome。这样既不破坏依赖 CDP 的既有自动化，也能继续支持那些 Chrome 独有、尚未被 WebDriver BiDi 标准化的用例。

项目的目标是：

• 提供一个参考实现，展示 Chrome DevTools 与 WebDriver BiDi 协议的能力。
• 推动自动化跨浏览器测试的采用。
• 帮助内部试用 DevTools Protocol 与 WebDriver BiDi 的新特性……顺便抓出 bug！
• 更深入地了解自动化浏览器测试的痛点，并帮助填补这些空白。

我们借鉴 Chromium 的原则来做产品决策：

• 速度：相比手动操作的页面，Puppeteer 的性能开销几乎为零。
• 安全：Puppeteer 在浏览器进程之外运行，因此自动化潜在恶意的页面也是安全的。
• 稳定：Puppeteer 不应时好时坏，也不应泄漏内存。
• 简单：Puppeteer 提供易于使用、理解和调试的高级 API。

Puppeteer 是一个基于 Node.js 的参考实现，演示如何用 CDP 与 WebDriver BiDi 自动化浏览器——而 Selenium 项目也在为同一套 Web 标准做贡献。

Selenium 项目在多个方面超出了 Puppeteer 的范围：它为 JavaScript 之外的语言提供绑定，还提供像 Selenium Grid 这样大规模编排自动化的工具。这两者都超出了 Puppeteer 的职责范围。

有一些社区项目在核心之外为 Puppeteer 增加能力，让测试等事情更方便，例如 jest-puppeteer 或 Puppeteer 的 Angular 集成。

每个 Puppeteer 版本都与特定的浏览器版本紧密绑定，以确保与底层协议实现（Chrome DevTools Protocol 与 WebDriver BiDi）兼容。这样做是为了防止 Chrome 或 Firefox 的变更意外破坏 Puppeteer。

查看 revisions.ts 中的 chrome 与 firefox 条目。

从 Puppeteer 的角度看，任何改变页面 URL 的事情都是“导航”。除了浏览器访问网络、从 Web 服务器获取新文档的常规导航之外，这还包括锚点导航与 History API 的使用。

按这个定义，Puppeteer 可以无缝地处理单页应用。

在浏览器中，输入事件可以分为两大类：可信（trusted）与不可信（untrusted）。

• 可信事件：用户与页面交互产生的事件，例如使用鼠标或键盘。
• 不可信事件：由 Web API 生成的事件，例如 document.createEvent 或 element.click()。

网站可以区分这两类事件：使用 Event.isTrusted 事件标志；或者嗅探伴随事件——例如每个可信的 click 事件之前都会有 mousedown 与 mouseup。

对自动化而言，生成可信事件很重要。Puppeteer 生成的所有输入事件都是可信的，并会触发正确的伴随事件。如果出于某种原因需要不可信事件，总可以进入页面上下文，用 page.evaluate 生成一个假事件：

await page.evaluate(() => {
  document.querySelector('button[type=submit]').click();
});

Puppeteer 默认使用 Chrome for Testing 二进制，从 M120 起它们自带专有编解码器支持。

我们有一份针对各种操作系统的故障排查指南，列出了所需的依赖。

获取帮助的方式有很多：

• 问题咨询：Stack Overflow
• bug 报告：GitHub Issues

发问之前，请先在这些渠道里搜索一遍。