Library Puppeteer 用Node控制Chrome与Firefox做自动化测试

做前端最怕两件事：一是手工点一遍页面验证功能，枯燥又容易漏；二是需要批量抓取或截图网页，却没有顺手的自动化手段，只能写脆弱的正则去抠 HTML。Puppeteer 给了 Node 开发者一个官方级的浏览器控制库，用几行代码就能驱动 Chrome、Firefox 完成点击、填表、截图与爬虫，把“用程序操作浏览器”这件事标准化。它让“像人一样打开网页并操作”变成了几行异步函数。

项目基本信息

一、项目介绍

Puppeteer 是 Google 维护的 Node 库，提供高级 API 来通过 DevTools 协议控制 Chrome 与 Firefox。它默认以无头模式运行，适合自动化测试、服务端渲染、页面截图与数据抓取。当前版本 v25.16.0，支持现代包管理器的脚本策略，并可与 chrome-devtools-mcp 等工具联动，进一步把浏览器操作交给 AI 智能体。它把浏览器自动化从“写复杂脚本”变成了“描述动作”。

Puppeteer 是 Node.js 生态里最主流的浏览器自动化库，由 Chrome 团队维护。它通过 DevTools 协议驱动 Chrome 或 Firefox，用一套高层 API 完成点击、输入、跳转、等待、截图、生成 PDF 等操作，把“像人一样操作浏览器”变成几十行代码就能搞定的事。与直接操作协议相比，它屏蔽了大量底层细节：自动等待元素就绪、处理弹窗、管理 Cookie 与登录态。它既是爬虫取数的利器，也是端到端测试与页面渲染的常用工具，生态里围绕它发展出了 PDF 服务、海报生成、监控告警等一大批衍生方案。

二、核心优势

一是官方级质量。由 Chrome 团队背景维护，兼容性与稳定性强，版本跟随浏览器迭代。二是 API 直观。选择器、点击、输入、等待事件都封装完善，上手快。三是生态成熟。配合 Jest、Vitest 做端到端测试非常顺手，社区示例丰富。四是多浏览器。同时支持 Chrome 与 Firefox，覆盖面更广，避免被单一内核绑定。五是可作为 MCP 工具被 AI 调用，紧跟智能体趋势。

第六，它自带无头模式，服务器上没有图形界面也能跑，资源占用可控。第七，支持请求拦截与响应篡改，可以做 Mock、屏蔽第三方脚本、统计资源加载。第八，能复用本机 Chrome 配置文件，免登录抓取需要会话的页面。第九，与 Playwright 形成互补，前者在 Chrome 生态与 PDF 生成上积累更深，后者在多浏览器覆盖上更广。第十，TypeScript 类型定义完善，大型项目里使用体验良好。

三、适用场景

适合做 Web 应用的端到端自动化测试；为页面生成预览截图与 PDF；批量采集公开网页数据；以及构建需要真实渲染的爬虫与监控脚本。当你需要“像人一样打开网页并操作”时，Puppeteer 是最直接的工具，无论是 CI 里的 e2e，还是定时抓取动态页面都胜任。

典型用法包括：定时抓取竞品价格并入库；对核心流程做端到端回归测试；把页面渲染成 PDF 或长图用于报告导出；批量截图做视觉巡检；自动化填写内部表单。对需要与老旧 Web 系统打交道的团队，它往往比改造接口更现实。

四、安装教程

安装主包，安装时会自动下载匹配的 Chrome：

npm i puppeteer

若不想自动下载浏览器，可用 puppeteer-core 并手动指定：

npm i puppeteer-core
npx puppeteer browsers install

注意新版包管理器默认阻断安装脚本，需放行 puppeteer 的脚本或手动安装浏览器，否则运行时会报找不到浏览器。CI 环境建议预装浏览器镜像以提速。

五、使用示例

下面脚本打开页面并截图：

import puppeteer from "puppeteer";
const browser = await puppeteer.launch();
const page = await browser.newPage();
await page.goto("https://example.com");
await page.screenshot({ path: "shot.png" });
await browser.close();

运行后会在当前目录生成 shot.png，完整渲染后的页面即被保存。把 page.goto 换成你的站点，就能批量生成预览图，或加入 page.type、page.click 模拟用户操作。

安装后写一个最小示例：

npm install puppeteer

import puppeteer from "puppeteer";

const browser = await puppeteer.launch();
const page = await browser.newPage();
await page.goto("https://example.com");
await page.screenshot({ path: "shot.png", fullPage: true });
await browser.close();

运行后会得到整页截图。做测试时可配合断言库，把“打开页面—执行操作—校验结果”固化成用例。

六、常见问题

问：装完报错找不到浏览器？多为安装脚本被拦截，执行 npx puppeteer browsers install 即可。问：能爬动态渲染页吗？能，它运行真实浏览器，JS 渲染后的内容都能拿到。问：和 Playwright 怎么选？两者能力相近，Puppeteer 与 Chrome 生态贴得更紧，Playwright 在多浏览器一致性上更细。问：耗资源吗？无头模式较轻，但并发需控制。

问：需要额外装浏览器吗？新版会自动下载匹配的 Chrome，也可指定可执行路径。问：服务器上缺依赖怎么办？官方文档列出了各系统所需基础库，按提示安装即可。问：和 requests 比呢？需要执行 JS 的页面必须用真实浏览器。

七、总结

Puppeteer 用 Apache-2.0 协议把“程序化控制浏览器”这件事标准化了。无论测试、截图还是抓取，它都是 Node 开发者工具箱里的常备库，把最繁琐的“人肉点页面”变成可重复、可编排的自动化。

在“页面即应用”的时代，浏览器自动化已经不是可选项而是基础设施。Puppeteer 用一套稳定的 API 把这能力交给了 Node 开发者，是值得长期投入学习的库。

再谈几个生产环境经验。服务器部署时，建议给 Puppeteer 单独的用户与资源限额，避免页面异常导致内存溢出拖垮机器；--no-sandbox 在容器里常需要，但要确认容器本身已做好隔离。第二，等待策略优先用显式等待而不是固定 sleep，既快又稳。第三，抓取前先看目标站的 robots 协议与服务条款，控制频率，做一个礼貌的自动化使用者。第四，把浏览器实例复用起来，频繁启动关闭的开销比想象中大，长任务建议单进程多页面。

再补充一点关于调试与维护的经验。把常用的等待、截图、导出逻辑封装成项目内的工具函数，别在每个脚本里重复写；这样目标站改版时只需改一处。第二，为关键抓取任务加上失败重试与告警，静默失败比报错更危险。第三，定期清理下载目录与用户数据目录，无头浏览器跑久了会占用大量磁盘。第四，把选择器集中管理，页面结构变化时按清单逐个更新，效率远高于临时在脚本里翻找。