大多数人认识 Crawlee 时，往往是在试图回答另一个问题："我该用哪种无头浏览器？" 这其实问偏了，而 Crawlee 恰恰说明了为什么。它不是浏览器，而是一个 Node/TypeScript 框架：需要时帮你套上一层浏览器，不需要时则直接跳过。
我用 Node v22.22.3 和 macOS，拿一组受控测试样本以及几个公开演示站点，对 Crawlee 3.17.0 连续跑了几天。它最核心的卖点——一个库、一个 API，底下既可以是 HTTP 爬虫，也可以是真正的浏览器——正是我最想重点验证的地方，因为这决定了 Crawlee 值不值得加入你的技术栈，还是你干脆直接用 Playwright 更省事。先说结论：这套双引擎说法是站得住的，不过也有一些需要打个星号的地方，后面会展开。
Crawlee 到底是什么，不是什么
Crawlee 将自己定义为一个面向 Node.js 的网页抓取与浏览器自动化库，目标是构建稳定可靠的爬虫。它的官方定位覆盖面很广：可以为 AI、LLM、RAG 或 GPT 提取数据；可以下载 HTML、PDF、JPG、PNG 等文件；兼容 Puppeteer、Playwright、Cheerio、JSDOM 和原始 HTTP；支持有头或无头模式；还自带代理轮换。功能面非常宽，所以更需要说清楚 Crawlee 不是什么。
它不是渲染引擎，也没有自带浏览器。需要执行 JavaScript 时，Crawlee 会驱动 Playwright 或 Puppeteer，而它们再去驱动 Chromium（或其他浏览器）。它也不是那种通过网络直接调用的托管服务，而是你安装在本地、自己运行的依赖。准确来说，Crawlee 是位于抓取器之上的那一层：爬虫类、请求队列、存储、链接跟随逻辑都在这里。你可以把它理解成“爬取框架”，下面留出一个可插拔的引擎位。
顺带一提，我测试的版本是 3.17.0（发布日期 2026-06-04），使用 TypeScript，许可证是 Apache-2.0；截至 2026-07-09，仓库 apify/crawlee 大约有 24.6k star。star 数会浮动——我观察的两天里它又涨了 53 个——所以这个数字只能当作快照，而不是固定事实。
两种引擎：CheerioCrawler vs PlaywrightCrawler
真正体现设计价值的地方就在这里，也是我花最多时间验证的部分。
CheerioCrawler 走的是 HTTP 路线。它直接通过网络获取原始 HTML，再用 Cheerio 解析——没有浏览器，没有 JavaScript 执行，也不会渲染页面。速度快、成本低。PlaywrightCrawler 则是浏览器路线。它会启动真正的 Chromium，把页面连同 JavaScript 生成的 DOM 一起渲染出来，甚至还能截屏。
这两个引擎能力确实不同，而 Crawlee 想表达的是：它们穿的是同一套“衣服”。二者都接受 requestHandler，都提供 run()，都能用 enqueueLinks 继续爬链。把一个引擎换成另一个，不需要重写，只是换类而已——我通过保持提取逻辑字节级完全一致，只替换包裹它的爬虫类，验证了这一点。
这里有一点需要说得非常准确，因为这正是两者开始分界的地方：内容获取对象不同。在 CheerioCrawler 的处理函数里，你拿到的是 $——一个静态、已经解析好的 DOM，可以像 jQuery 那样查询。在浏览器处理函数里，你拿到的是实时的 page 对象。所以，队列、路由、“把这批数据推进去、把那些链接继续追下去”这些基础设施保持不变，但真正读取页面内容的那一层会变形。Crawlee 自己的文档也明确说过这一点——它把共享接口限定在爬取操作上，而把内容访问方式作为差异点。
| 引擎 | 获取方式 | 支持 JavaScript？ | 我的测试结果（1 个动态页面） | 适用场景 |
|---|---|---|---|---|
CheerioCrawler | 原始 HTTP + Cheerio 解析 | 否 | ~0.035 秒 | 静态 HTML、JSON API、追求速度 |
PlaywrightCrawler | 通过 Playwright 驱动真实 Chromium | 是 | ~4.967 秒 | JavaScript 渲染页面、截图 |
这些耗时来自单台机器、单次运行——不是严格基准测试，只是体现取舍的轮廓。同一个 URL 上，浏览器路线花的时间大约比 HTTP 路线多两个数量级。这就是渲染的成本，也解释了为什么它不应该默认启用。
测试结果：同一个 URL，0 对 8/8
口说无凭。之所以我相信这套双引擎说法，是因为我能先把它跑失败，再通过换一个类把它修好。
我构建了一个本地动态样例页面——一个商品列表页面，商品卡片是页面加载后由 JavaScript 注入的，也就是现代网站里越来越常见的那种结构。我把它交给 CheerioCrawler，结果返回 0 个商品卡片。这不是 bug，而是物理规律：Cheerio 根本没有执行 JavaScript，所以解析到的 HTML 里压根没有这些卡片。随后我把完全相同的 URL 交给 PlaywrightCrawler，除此之外什么都不改，它就成功渲染出 8/8 个商品，并截了一张图作为证据。
为了确认这不是我自己样例的偶然现象，我又在一个公开站点上重复了同样的流程——Quotes to Scrape 这个 JavaScript 演示页，引用内容是客户端生成的。结果完全一致：CheerioCrawler 看到 0 条引用，PlaywrightCrawler 则成功提取到 10 条。
我想谨慎说明一下这能证明什么。这其实是对 Crawlee 已经文档化的能力做了一次干净复现——从 3.0 版本开始，这个框架的各类爬虫就共享同一个基类和接口。所以这不是发现新功能，而是验证它确实如此。但这正是它的价值所在："一个接口，HTTP 或浏览器都能跑" 这句营销话术是真的，而且在我可控的样例和我无法控制的网站上，都拿到了 0 → 完整数据的结果单。
HTTP 路线为什么更有优势
上面那部分很容易让人得出“那就永远用浏览器吧”的结论。别急。双引擎设计之所以重要，正是因为浏览器是昂贵的兜底方案，而不是默认选项。
在静态内容上，CheerioCrawler 既准确又快。我的静态商品样例返回了 12/12 个商品，并通过 enqueueLinks({ selector: '.next-page' }) 跟踪分页，整个过程大约只用了 0.155 秒。另一篇文章页面则能干净地提取出标题和 3/3 段正文，同时把登录/订阅/版权等模板内容和正文区分开来。
更值得记住的是这一点：一个由 JavaScript 加载数据的页面，背后通常都藏着一个 JSON API。我的动态样例的数据就存放在一个接口里，而当我让 CheerioCrawler 直接请求这个 API 时，它在大约 0.035 秒内恢复出了 8/8 个商品——不需要浏览器。相同数据，浏览器路径却要接近五秒才能渲染出来。这个道理老生常谈，但依然成立：如果你能复现底层请求，就别去启动 Chromium。Crawlee 让你可以按爬虫粒度做这个选择，而且不用切换框架。
为什么说它是“爬取框架”（也是为什么它比单纯浏览器库更值得选）
如果你只需要渲染一个页面，根本不需要 Crawlee——直接用 Playwright 或 Puppeteer 就够了。单纯的浏览器库不会给你的是“爬取”：队列、去重、深度控制、重试。这才是 Crawlee 真正不依赖引擎的部分。
我从一个样例根页面出发，使用 enqueueLinks 并跟踪深度做了一次同域爬取。Crawlee 一共走了 11 个页面，深度分布为 {0:1, 1:3, 2:7}——也就是 1 个根页面、1 跳外 3 个页面、2 跳外 7 个页面——并且把 maxRequestsPerCrawl 当作停止条件正常执行。RequestQueue 负责所有调度与记录。另一方面，当我把请求打到一个返回 HTTP 500 的页面时，Crawlee 会先重试，然后通过 failedRequestHandler 抛出失败，而不是悄悄吞掉错误或者直接把整个任务搞崩。
这就是 Crawlee 相比独立浏览器工具最强的理由：爬取编排已经内建，而且无论底层引擎是 HTTP 还是浏览器，编排方式都一样。你只需要写一次队列和链接跟随逻辑，再分别决定每个爬虫是否需要渲染 JavaScript。
安装体验和隐藏的浏览器下载
安装过程总体顺利，但有一个新手很容易踩的坑。
npm install crawlee playwright 可以正常完成，0 个漏洞报告。但 PlaywrightCrawler 不能直接启动，你还必须运行 npx playwright install chromium，它会额外下载一个约 81.7 MiB 的 Chromium 二进制文件。只安装 crawlee 包并不会自动拉取浏览器。如果你跳过这一步，直接跑浏览器爬虫，就会遇到一个启动错误；如果你不熟悉 Playwright 的打包方式，这个报错并不直观。这不是 Crawlee 本身的缺陷，而是继承自 Playwright 的行为，但它确实是第一次上手时很容易卡住的地方，值得提前提醒。
还有一点运维上的小提醒：Crawlee 默认会把数据写到本地 storage/ 目录。我的测试框架把它重定向到了临时目录，并关闭了持久化，保持环境干净；但如果你直接按默认方式跑，项目里会多出一个 storage/ 文件夹。不是问题，只是你在 git status 里看到它时别意外。
简单说一下第三种引擎
Crawlee 的兼容性故事不只停留在 Cheerio 和 Playwright。它还有 PuppeteerCrawler，我也顺手检查了它和“同一接口”这个说法到底能走多远——这里我只做了类和 API 表面的检查，没有实际跑爬取任务。
这三种爬虫类都可以追溯到同一个 BasicCrawler 基类。CheerioCrawler 走的是 HttpCrawler；PlaywrightCrawler 和 PuppeteerCrawler 则都走同一个 BrowserCrawler。我对已安装包做了静态检查，发现三种引擎之间有 24 个公共公开方法，包括整个设计依赖的队列与存储操作：run、addRequests、pushData、getData、getDataset、exportData、getRequestQueue、useState、stop。实际上，PuppeteerCrawler 和 PlaywrightCrawler 暴露的公开方法集合完全一致。跨引擎差异只存在于 HTTP 与浏览器的分界线上，这也正是最合理的地方。
需要明确说清楚的边界是：我没有实际运行 PuppeteerCrawler 的爬取任务。我的测试环境里没有安装可选的 puppeteer 依赖，而且如果要测它，还得再下载一个浏览器。所以这里验证的是结构层面的兼容性——相同的基类、相同的共享方法、相同的处理函数上下文结构——而不是一次真实执行的结果。即便接口一致，底层行为也不会完全一样：Crawlee 自己的官方说明提到，Playwright 会自动等待元素，而 Puppeteer 则需要你显式等待。这属于引擎差异，不是 Crawlee 的问题，但它意味着“API 一样”并不等于“处理函数内部的写法完全一样”。
我没有测试的内容
这一轮测试有意留下了以下几项没有覆盖，避免你把结果理解得比它实际更广。
- 规模。 所有运行都基于小样例和短篇公开站点爬取，没有做 100–1,000 页的大规模长跑，所以我无法评价 Crawlee 在真实负载下的自动扩展能力或稳定性。
- 队列持久化与恢复。 我没有在爬取中途强制终止任务，因此无法确认
RequestQueue在崩溃后是否能无缝继续。 - Dataset 和 KeyValueStore 导出。 我的测试框架里是手写 JSON/CSV 导出，没有体验 Crawlee 内置
Dataset/KeyValueStore的导出便利性——而这其实可能是使用这个框架的核心收益之一。 - 代理与会话池。 Crawlee 自带代理轮换和指纹识别相关功能。我把这些功能严格看作合规和运维工具，而不是“绕过反爬”的卖点，因此也没有对它们做压力测试。
另外，文中所有耗时都来自单机单次运行。它们展示的是 HTTP 和浏览器路线之间成本差异的“形状”，不是正式基准测试，我也不会把它们当成 benchmark 来引用。
优缺点总结
优点
- HTTP 抓取和浏览器抓取共用同一套 API——引擎切换确实只是换类；在本地样例和公开站点上都验证了 0 → 完整数据的结果。
- 真正的爬取框架：不仅有页面渲染，还有
RequestQueue、带深度控制的enqueueLinks、重试机制和failedRequestHandler。 - 在没有 JavaScript 干扰时，HTTP 提取非常准确（静态内容 12/12、文章正文 3/3、通过 JSON API 取到 8/8）。
- 浏览器路径可以拿到 HTTP 路线根本看不到的内容，还能截屏。
- Apache-2.0 许可证、TypeScript 编写、持续维护中。
缺点
- 浏览器爬虫需要额外执行
npx playwright install chromium（约 81.7 MiB），而npm install crawlee不会自动处理这一步——很容易漏掉。 - 浏览器渲染确实有明显的单页成本（我这次测试里约 5 秒，对比亚秒级的 HTTP 路线）。
- 默认运行会在项目中留下
storage/目录。 - 我没有验证规模、队列持久化/恢复、以及内置导出在大场景下的表现。
- 代理和指纹识别功能必须在网站条款和法律允许的范围内使用——这是责任，不是可以随意依赖的“功能”。
什么时候选 Crawlee，什么时候选托管 API
Crawlee 是一个“自己搭建”的工具，而对很多团队来说，这正是最合适的选择。当你想把爬虫掌握在自己的 Node 代码库里，希望在同一个项目里同时混用 HTTP 和浏览器抓取，又想自己控制队列和存储时，就该选它。如果你也愿意运行并最终扩展一整套浏览器集群，Crawlee 会给你一个结构清晰、设计成熟的骨架。
另一条路，则是不去操心这些基础设施。如果你不想把工程时间花在维护 Chromium 实例、代理轮换和反爬处理上，那么托管 API 就是替代方案——这也是 Thunderbit 自己的开发者技术栈所在。对技术用户来说，Thunderbit 不是 Chrome 扩展，而是一个 AI 抓取 API、MCP 服务器和 CLI。你可以调用 POST /distill 把网页转换成干净、适合 LLM 的 Markdown，也可以用带 JSON Schema 的 POST /extract 返回结构化数据，并通过 renderMode 选择 none、basic 或 full，决定何时值得做完整浏览器渲染。MCP 服务器 让 AI agent（如 Claude、Cursor 和其他 MCP 客户端）可以在任务进行中直接抓取网页，而 CLI 则能在终端或 CI 中运行：
npx -y @thunderbit/thunderbit-cli distill "<url>" -f markdown > out.md
对开发者来说，关键区别在于：Crawlee 给你的是原材料——渲染后的 HTML、解析后的节点——然后由你自己负责整条流水线；托管 API 则直接返回符合 schema 的结构化 JSON，浏览器渲染、CAPTCHA 和反爬处理都在服务端完成。两种方案适合不同任务。如果你想要最大控制权，而且不介意运维复杂度，就选 Crawlee；如果你更希望拿到数据本身，而不是维护浏览器集群，就选托管 API。很多团队最后会两者并用：一个做定制化爬取，一个处理“直接把结构化数据给我”的场景。你可以在 Thunderbit 定价页 看看这类方案的成本差异。
结论
要不要用 Crawlee？答案是：要——如果你是 Node 或 TypeScript 开发者，想要一个能同时覆盖 HTTP 和浏览器抓取、底层还有真正队列支撑的统一框架。它的双引擎承诺正是你选择它的理由，而我的测试样例证明这点成立：同一个 URL，只换一个类就能从 0 变成完整数据；静态提取准确且快速；队列和深度爬取也都按文档表现正常。
不过有两点你要提前知道。第一次使用 PlaywrightCrawler 时，要预留隐藏的浏览器下载成本；另外，不要假设我没有测试的那些部分——规模、崩溃恢复、内置导出——在你的真实工作负载上也会和我测到的部分一样可靠。作为你自己搭建爬虫系统的基础，Crawlee 是一块设计扎实、工程质量很高的底座；但如果你要的是一个已经完成、无需操心的端到端数据管道，它只是起点，不是终点。
免费试用 Thunderbit 进行网页数据提取 Get Started Free
常见问题
Crawlee 免费吗？它的许可证是什么？
是的。Crawlee 是开源项目，采用 Apache-2.0 许可证，可通过 npm 安装（npm install crawlee）。我测试的版本是 3.17.0。运行浏览器爬虫还需要通过 Playwright 额外下载 Chromium；这个组件本身也是免费的，但会让你的环境多占用约 81.7 MiB。
CheerioCrawler 和 PlaywrightCrawler 应该怎么选？
如果数据已经在原始 HTML 里，或者藏在底层 JSON API 里，就用 CheerioCrawler——它快得多，而且不会启动浏览器。如果内容是 JavaScript 渲染出来的，尤其当 HTTP 路线返回空结果时，就用 PlaywrightCrawler。我的测试里，HTTP 引擎在一个 JS 渲染页面上只返回 0 条，而浏览器引擎则能全部拿到。因为它们共用同一套 API，所以切换只是换类，不需要重写。
Crawlee 运行一定要浏览器吗？
只在使用浏览器爬虫时才需要。CheerioCrawler 完全不需要浏览器。PlaywrightCrawler（以及 PuppeteerCrawler）则需要浏览器二进制文件——用 npx playwright install chromium 安装即可。要注意，单独执行 npm install crawlee 并不会自动下载浏览器，这是最常见的新手坑之一。
Crawlee 能处理分页和多页爬取吗？
可以，而且这正是它比单独使用浏览器库更值得选的原因之一。enqueueLinks 能跟踪链接（包括像 .next-page 这样的分页选择器），RequestQueue 会负责去重和管理整个爬取过程，你还可以设置深度控制和 maxRequestsPerCrawl 限制。在测试中，一个同域爬取一共遍历了 11 个页面，深度从 0 到 2，失败请求也会通过 failedRequestHandler 显示出来。
Crawlee 和托管抓取 API 有什么区别？ Crawlee 是自托管的：爬虫由你编写和运行，扩展、代理和反爬处理都要你自己负责。像 Thunderbit 这类托管 API 则会直接返回干净的 Markdown 或与 schema 匹配的结构化 JSON，浏览器渲染和反爬处理都在服务端完成，并通过 API、MCP 服务器和 CLI 提供能力。想要最大程度掌控自己的数据流水线，就选 Crawlee；不想自己维护和扩展浏览器基础设施，就选托管 API。
