网络抓取归结为一个影响后续一切的早期决策:你是运行自己的无头浏览器,还是调用抓取 API?无头浏览器(Puppeteer、Playwright 或 Selenium)给你完全控制真实渲染引擎的权限。抓取 API 将该引擎隐藏在单次 HTTP 请求之后,并处理通常会破坏爬虫的部分。两者提取相同的数据,只是将工作量放在不同的地方。

本文对无头浏览器与 API 抓取进行了正面比较:每种方式实际做什么,各自适合哪些场景,以及你选择任一方式所承担的成本和运营负担。文中对权衡取舍持坦诚态度,包括人们最常忽略的细节:抓取 API 本身可以在服务器端驱动无头浏览器,所以"API"并不意味着"无渲染"。

无头浏览器与抓取 API:简要对比

维度 无头浏览器 抓取 API
你负责管理 浏览器、代理、反爬虫、扩展 单次 HTTP 调用
JS 渲染 自己运行 通过 JS token 在服务器端渲染
最适合 复杂流程、完全控制 大量抓取和保持不被封锁

一句话总结:无头浏览器给你控制权并承担运营负担;API 以牺牲部分控制权换取将渲染、代理和反爬虫折叠到单次请求中。

无头浏览器究竟是什么

无头浏览器是一种在没有可见窗口的情况下运行的真实浏览器引擎。它加载页面、执行 JavaScript、应用 CSS、触发事件,并将结果 DOM 暴露给你的代码,就像你桌面上的 Chrome,只是没有图形界面。你用一个库来驱动它:Puppeteer 或 Playwright 驱动 Chromium 和 Firefox,或者 Selenium 跨多个引擎运行。

因为它运行页面的 JavaScript,无头浏览器能看到普通 HTTP 请求永远看不到的内容。现代网站在初始 HTML 加载后在客户端渲染列表、价格和信息流,所以普通请求返回的是空框架。无头浏览器等待这些脚本运行,然后读取完成后的页面。它还可以交互操作:点击按钮、填写表单、滚动触发懒加载、经历多步骤流程。

以下是一个最小的 Playwright 运行示例,渲染页面并读取其内容。

javascript
const { chromium } = require('playwright')

async function run(url) {
  const browser = await chromium.launch()
  const page = await browser.newPage()
  await page.goto(url, { waitUntil: 'networkidle' })
  const html = await page.content()
  await browser.close()
  return html
}

这段代码片段是容易的部分。困难的部分是当你将同一个脚本指向真实的、有防御措施的目标时,周围的一切。

无头浏览器在哪里变得沉重

单个浏览器实例没问题。一组浏览器集群就是一项运营工作。每个实例在内存中持有一个 Chromium 进程,通常是数百兆字节,因此并行运行数百个实例意味着真实的机器和真实的内存预算。它们会崩溃、泄漏,并在缓慢的页面上挂起,所以你需要监督、重启和超时处理。而且渲染本身就很慢:你在加载你不关心的图像、字体和脚本,只是为了获取几个字段。

除此之外,页面可以判断它正在被自动化。网站会探测无头浏览器指纹(缺少浏览器插件、自动化标志、奇怪的时序),并挑战或封锁看起来像机器人的访问。保持不被封锁意味着隐身补丁、住宅 IP 轮换,以及 CAPTCHA 策略,而这些无头库都不会给你提供。如果你走这条路,我们关于如何在不被封锁的情况下抓取网站的指南涵盖了保持运行健康的习惯,使用 Python 和 Selenium 进行网络抓取提供了完整无头技术栈的端到端演示。

抓取 API 的替代方式

抓取 API 将渲染、代理池和反爬虫处理从你的机器移到一个端点之后。你发送给它一个 URL;它返回页面内容,通过目标信任的 IP 获取,如果你需要的话还进行了渲染。你永远不需要启动浏览器,永远不需要管理代理列表,永远不需要编写隐身代码。一个无头构建需要数十个活动部件才能安全完成的相同请求,变成了单次调用。

Crawlbase Crawling API 正是围绕这一点构建的。你向它传递目标 URL 和 token;它在服务器端处理其余部分并返回 HTML。将上面整个无头设置与一次请求进行比较。

javascript
const { CrawlingAPI } = require('crawlbase')

const api = new CrawlingAPI({ token: 'YOUR_CRAWLBASE_JS_TOKEN' })

api.get('https://www.example.com/products', { ajax_wait: true, page_wait: 5000 })
  .then((response) => console.log(response.body))

这单次调用取代了启动浏览器、轮换 IP、等待 JavaScript 和绕过检测的工作。选项也可以延续:ajax_wait 等待异步内容,page_wait 添加固定延迟,使延迟渲染的元素在 HTML 返回之前出现。

"API"并不意味着"无浏览器"

这是人们在无头浏览器与 API 抓取争论中常常忽略的细节。当你要求时,抓取 API 仍然渲染 JavaScript:传递 JavaScript(JS)token,Crawling API 就会在服务器端的真实浏览器中运行页面,然后返回完成后的 DOM。普通 token 只获取静态 HTML。所以渲染并没有消失,它只是从你的基础设施移到了他们那里。

详细比较

两种方式最终都能得到可用的数据。它们的不同之处在于工作量的位置、各自如何扩展,以及你在金钱和运营时间上支付的代价。下表并排列出了权衡取舍。

因素 无头浏览器 抓取 API
控制权 完全:每次点击、等待和拦截都由你来编写脚本 受限于 API 公开的选项
JS 渲染 你自己运行引擎并调整等待 通过 JS token 在服务器端渲染;普通 token 用于静态页面
代理和反爬虫 你采购 IP、轮换它们并编写隐身和 CAPTCHA 处理 轮换、可信 IP 和反爬虫已内置
扩展和运营 需要配置、监督和重启的内存密集型集群 并发是提供商的问题;你发送更多请求
成本 服务器、带宽、代理,加上你的工程时间 按请求定价;无集群或代理账单
最适合 需要完全控制的定制交互流程 保持不被封锁是困难所在的大量抓取

看"扩展和运营"及"代理和反爬虫"两行,模式很清晰:无头一列大多是你必须构建和持续运行的事情,而 API 一列将这些相同的关注点折叠到服务中。

什么时候无头浏览器是正确选择

当工作需要真正的交互或不寻常的控制时,拥有浏览器的运营负担是值得的。在以下情况下使用无头浏览器:

  • 流程是交互式的。 多步骤表单、拖放操作、根据滚动位置加载的无限滚动,或任何依赖精确事件序列的操作,在你直接编写浏览器脚本时最容易实现。
  • 你需要浏览器级别的工件。 全页截图、PDF 或性能追踪来自引擎本身。(如果截图是全部目标,托管的Screenshots API 无需集群即可为你提供。)
  • 量少且目标友好。 在不抵制机器人的网站上每天只有少量页面,很少需要付费服务。
  • 你同时也在测试。 如果相同的无头设置同时作为你的 UI 测试工具,你已经在为其成本买单了。

什么时候抓取 API 更胜一筹

当"大规模保持不被封锁"成为真正的问题而不仅仅是渲染本身时,API 就赢得了它的地位。在以下情况下选择 API:

  • 量大。 跨多个域名的数千个页面通过发送更多请求来扩展,而不是通过配置更多浏览器。
  • 目标积极防御。 当 IP 声誉和反爬虫是那道墙时,拥有大量住宅代理池的服务比自托管集群更可靠地通过它。
  • 你想要干净的字段,而不是原始 HTML。 Crawling API 为支持的网站返回解析后的 JSON,让你省去编写和维护选择器。
  • 工程时间是稀缺资源。 将渲染、轮换和反爬虫卸载给 API,让小团队无需运行抓取基础设施就能交付成果。

还有一条中间路径。如果你有现有的 HTTP 爬虫,只需要 IP 和反爬虫层,Smart AI Proxy 端点可以作为直接替换代理接入,而无需更改你的解析方式,同时你保持自己的客户端。

Crawlbase Crawling API

跳过无头浏览器集群和代理池。发送带 JS token 的 URL,Crawling API 在服务器端的真实浏览器中渲染页面,轮换住宅 IP,处理反爬虫,并在单次调用中返回完成后的 HTML。你的前几次请求是免费的。

你不必只选其一

框架是"无头浏览器与 API 抓取",但生产技术栈通常两者都用。一个常见的模式:针对无头浏览器进行原型设计以理解棘手的流程,观察网络选项卡以找到页面调用的内部 JSON 端点,然后在批量运行时切换到 API 或直接请求这些端点。无头浏览器是你的发现工具;API 是你的生产引擎。

另一个使界限模糊的原因是上面标注框中提到的。带 JS token 的抓取 API 在为你运行一个无头浏览器,在服务器端,因此选择它并不是"没有无头浏览器"。它是"别人的无头浏览器,保持隐蔽并扩展,在单次请求之后"。这将决策从技术决策重新框定为运营决策:你想运行和维护渲染与反爬虫层,还是付费让别人为你运行?

回顾

核心要点

  • 无头浏览器给你控制权,自己承担负担。 Puppeteer、Playwright 和 Selenium 给你完全控制真实引擎的权限,但你自己运行集群、代理和反爬虫。
  • API 将困难部分折叠为单次调用。 渲染、IP 轮换和反爬虫从你的机器移到单次请求之后。
  • "API"仍然渲染。 JS token 在服务器端驱动真实浏览器,所以抓取 API 不是无渲染选项,渲染只是移到了提供商那里。
  • 无头浏览器适合交互式、低量或与测试共享的工作。 复杂流程和浏览器工件证明了拥有引擎的合理性。
  • API 适合大量抓取和有防御措施的目标。 当大规模保持不被封锁是真正的问题时,服务一列在运营和成本上胜出。
  • 两者结合是正常的。 用无头浏览器进行发现,通过 API 或直接端点调用运行生产。

常见问题

无头浏览器和 API 抓取有什么区别?

无头浏览器是你自己运行的真实浏览器引擎,用于渲染页面、执行 JavaScript 和驱动交互;你还拥有其周围的代理、反爬虫和扩展。抓取 API 将渲染、IP 轮换和反爬虫放在单次 HTTP 请求之后,所以你发送一个 URL 并获取内容,而无需管理任何基础设施。

抓取 API 比无头浏览器快吗?

对于大量工作,通常是的,因为提供商在优化的基础设施上运行渲染,并为你处理并发,所以你通过发送更多请求来扩展,而不是通过配置更多浏览器实例。单次本地无头运行可能感觉差不多,但一旦你添加代理和反爬虫处理,它就不能以同样的方式扩展。

使用抓取 API 意味着不会发生 JavaScript 渲染吗?

不。当你要求时,抓取 API 仍然渲染 JavaScript。使用 Crawlbase Crawling API,你传递 JavaScript(JS)token,页面在返回 HTML 之前在服务器端的真实浏览器中运行。普通 token 只获取静态 HTML。渲染不会消失,它从你的机器移到提供商那里。

我可以同时使用无头浏览器和抓取 API 吗?

可以,这是一种常见的设置。许多团队用无头浏览器进行原型设计,理解棘手的页面并找到其内部 JSON 端点,然后切换到抓取 API 或直接请求这些端点进行高量生产运行。无头浏览器是发现工具;API 是生产引擎。

我什么时候应该避免运行自己的无头浏览器?

当量大或目标积极防御时,应避免使用,因为自托管集群意味着配置内存密集型浏览器实例、采购和轮换代理,以及编写隐身和 CAPTCHA 处理,而托管 API 都已包含这些。如果大规模保持不被封锁是你的主要问题,API 通常是更好的权衡。

无头浏览器和抓取 API 哪个更便宜?

这取决于量。在友好网站上量少时,自托管无头浏览器可以实际上是免费的。在规模上,一个健康集群的服务器、带宽、代理和工程时间成本,通常超过按请求 API 定价,特别是当你考虑保持其不被封锁的维护工作时。

开始构建

大规模爬取任何站点,无需与基础设施对抗。

Crawlbase 负责处理代理、指纹和 CAPTCHA,让你的团队专注于交付数据流水线,而非维护爬取管道。1,000 次请求免费,无需信用卡。

自助开通 · 无需销售通话 · 提供企业级爬取量