Apify 替代方案：大规模网页抓取（百万页以上）

在百万页这个量级下，真正推高成本的往往不是爬虫本身，而是代理带宽、失败重试和浏览器渲染。因此，在评估 Apify 的替代方案时，不能只比较表面价格，更重要的是看不同工具如何处理这些实际产生的成本。

单纯从 Apify 换到另一个平台，并不会自动降低抓取成本。更有效的做法，是先区分哪些页面真正需要浏览器。如果 API 或普通 HTTP 请求已经能够获取所需数据，就直接使用它们；只有涉及 JavaScript 渲染、点击翻页、表单提交或登录会话的任务，才需要进入浏览器。

这样拆分之后，不同工具适合处理的任务也会清晰很多。Apify、Firecrawl 或自建爬虫更适合大规模处理公开、可直接访问的数据；当工作流进入真正依赖浏览器状态和交互的环节时，就可以交给 ego (lite) 来完成。

原因在于，这类任务已经不只是“获取一个页面”。Agent 需要处理渲染后的内容、当前浏览器状态和页面交互，下一步操作也可能根据页面返回的结果动态变化。ego (lite) 直接运行在真实浏览器环境中，让 Agent 能够读取当前页面、继续完成交互，并在需要人工判断或接管时，将控制权自然地交回给用户。

因此，对于大规模任务，更合理的方案通常不是寻找一个工具替代整个 Apify 工作流，而是根据任务类型选择合适的执行方式：能用 API 或 HTTP 完成的部分保持简单，需要大规模抓取的部分交给专门的爬虫，而真正依赖浏览器环境和交互的步骤再使用 ego (lite)。这样既能控制成本，也能避免为不需要浏览器的任务支付额外的浏览器运行开销。

在 Apify 上抓取一百万页要花多少钱？

按下面这些数字，大约是 $430 到 $1,300，其中 80% 以上是代理带宽，而不是抓取本身。

这套算法背后的费率公布在 Apify 的定价页。

计算单元如何计数，文档见 Apify 的使用与资源文档。

这个估算是基于 Apify 公开费率推导的，不是账单，也不是报价。它假设有一百万个目标 URL，其中占大头的那部分走 Cheerio 风格的 HTTP 请求，约 10 万个确实需要 JavaScript 的页面走浏览器渲染，整轮都使用住宅代理。

在这个量级上做规划时，有一点比其他都重要。请求量不等于页面量。如果 85% 的请求一次成功，那么一百万目标页在重试之后会接近 115 万到 130 万次请求。你为请求付费，也为它们的带宽付费，哪怕有些请求返回的是空结果。

我们的成本模型，逐项拆开。

把这当成一次基于公开价格的算术练习。我们是用 Apify 的费率去套一个明确设定的工作量，所有假设都写出来了，方便你换成自己的数据。

表中有两个数字值得再看一眼，因为预算出问题通常就出在这里。

第一个是 1024MB 这一行。新手常常以为买更大的内存就会更贵。按 CU 算并不会：一个需要两倍内存的任务，运行时间会减半，而计费看的是两者的乘积。内存是调度旋钮，不是省钱杠杆。

第二个是代理这一行。注意平台费在这里根本不可能占大头：按套餐不同，每个 CU 是 $0.20 到 $0.13，你得烧掉 2000 多个计算单元才能抵得上一张中等规模的带宽账单。

如果你的抓取很贵，你付的是带宽，不是编排。

Apify 的计算单元（CU）计费模型到底怎么算？

一个计算单元就是 1GB 内存占用一小时，按一秒粒度计量，也是平台唯一用来给爬取计费的单位。

内存乘以时长。一个占 1024MB、跑一小时的运行正好花 1 CU；同样一个运行改成 4096MB 跑十五分钟，也是 1 CU。这就是为什么调整 worker 规格时，我们模型里的 CU 那一列几乎不动，工作量就是工作量。

这个模型有几个性质值得记住：

1. Cheerio 不是一点小优化。 按 Apify 自己的说法，同样一个任务走 Cheerio 风格的 HTTP 请求，比在浏览器里跑快 20 倍。正是这个倍数，让一百万页只需要 170 CU 成为可能。
2. 决定墙钟时间的是并发，不是 worker 规格。 各套餐的并发限制从 Free 的 25 个并发运行到 Business 的 256 个，对应层级的合并内存上限分别是 16,384MB、65,536MB、262,144MB 和 524,288MB。按 32 个并发任务、每分钟约 3,200 页计算，一百万页大约要 5.2 小时。
3. 有些 actor 有硬性内存下限。 浏览器 actor 无法在 1024MB 以下运行，Google Maps 抓取器则需要 4096MB 或更多。如果你不想按 actor 逐个调参，4096MB 是务实的默认值。
4. credit 不会结转。 每月未用完的 credit 会过期。如果你的抓取是突发式的，比如每季度跑一次大规模任务，而不是细水长流，那你就是在为没用上的容量付费。

以上都不是反对 Apify。它是少数几个你可以照着公开文档推算单位经济性的平台之一，CU 模型也确实诚实：它按工作量收费，而不是按行数。问题在于它不包含哪些成本。

代理。渲染密集的 actor。数据集放着不动却持续累积的存储。这些才是决定百万页抓取是花几百美元还是几千美元的项目，而无论你考虑哪个 Apify 替代方案，都是这些项目。

大规模抓取有哪些主要的 Apify 替代方案？

替代方案有四类，其中只有一类和 Apify 的计价方式形状相同。

大多数 Apify 替代方案清单，其实是别的抓取网站工具清单，那是另一个问题。如果你的抓取是贵，而不是做不到，那关键维度就不是功能，而是各家按什么收费。每计算小时的价格、每 credit 的价格、每 GB 代理流量的价格、每人工小时的价格，在量级增长时表现完全不同。

1. Firecrawl。 按 credit 计费的抓取 API，输出可直接喂给 LLM。一次抓取消耗一个 credit，每个可选输出格式都要加钱：JSON 模式 +4，问题或要点提取每个格式 +4，PII 脱敏 +4。套餐价格为 $0、$20、$106、$424、$762，分别对应每月 1,000、5,000、100,000、500,000 和 1,000,000 个 credit。
2. ZenRows。 托管式抓取，支持 JS 渲染和代理轮换。credit 从 $16 套餐的 5,000 到 $456 套餐的 500 万，并发从 5 到 200，更高可定制。JavaScript 渲染会把 credit 成本乘以 10，JS 加代理的组合模式乘以 25。失败和重试的请求不计费。
3. ScraperAPI。 按 credit 计费的抓取服务，并发阶梯很直接，从 $49 套餐的 20 到顶配的 500 以上，credit 覆盖 100,000 到 1,050 万。
4. Bright Data 和 Oxylabs。 以代理为主、同时卖托管抓取器的厂商。Oxylabs 列出的 SERP 价格是每次 unit sequence $0.50 到 $1.35，住宅带宽按量从 $3/GB 降到 $2/GB。Bright Data 的 web-scraper 页面强调不限并发，却没有公布价格，这是我们无法核实的说法，因此不作为事实转述。
5. 自建爬虫。 在自己基础设施上跑 Scrapy 或 Playwright 流水线。完全没有按页或按 CU 的费用，代理账单该怎么付还是怎么付。代价是队列管理、重试、调度和监控从此永远是你的事。
6. Agent 驱动的浏览器。 这条路线正是我们在做的，所以请带着这个前提看。ego (lite) 是一个 Chromium 浏览器，会沿用你现有的登录状态和扩展程序，编程 Agent 在它自己隔离的 Space 里通过 ego-browser Skill 驱动它。当静态请求开始不够用时，工作流就会走到这里：需要登录的步骤、只在 JavaScript 下渲染的视图、藏在点击之后的翻页、本质是表单的筛选、要从收件箱读取的验证码。它免费，目前运行在 macOS 上，Windows 和 Linux 在路线图中。它没有可以和 Apify 对标的按页费率，所以该问的不是哪个按页更便宜，而是你的工作流到底需不需要会话。

为什么代理带宽占了大头？

因为它是唯一按你下载页面的大小、而不是按你做了多少工作量来计费的项目。

这条路在同等条件的浏览器任务上表现如何，ego (lite) 与 Playwright 的对比就是最直接的。

如何在多次运行之间保持已登录的会话，详见 Agent 运行之间的持久浏览器会话。

计算成本随 CPU 时间增长。并发随套餐层级增长。带宽随互联网增长。一兆字节的 HTML 就是一兆字节，不管它花了 1 毫秒还是 1 秒才到达，而住宅代理流量按 GB 计价：Apify 是 $8/GB，Oxylabs 按量从 $3/GB 降到 $2/GB。

按每页 50KB 压缩 HTML 算，一百万页大约是 50GB。按 Apify 标出的费率就是 $400，还没算重试，而且目标越难越糟：有反爬保护的页面更重，往往要多次请求才能拿到结果，消耗的资源最高可达普通页面的三倍。

接下来是不太舒服的部分。这些带宽大部分都浪费掉了，而且你心里清楚。一个商品列表页可能有 400KB 的 HTML、CSS、JavaScript、字体和跟踪像素，只为了让你读到一个价格和一个库存状态，而真正的信号可能只有 2KB。你在用住宅代理的价格搬运包装盒。

有三个杠杆能把它降下来，它们比换任何厂商都更有价值。把抓取范围限制在真正带数据的页面上，而不是顺着每个链接爬。在网站提供结构化接口的地方直接请求接口，因为 JSON 响应只占渲染后页面体积的一小部分。只在必须渲染的地方渲染，在我们的模型里，一百万页中只有 10 万页需要。

这些 Apify 替代方案对比起来如何？

按公开费率算，最便宜和最贵的路线之间相差大约十倍，而这十倍都不来自抓取本身。

看每一行时关注两件事：厂商按什么收费，以及它会限制你做什么。有价格没有上限是营销话术，有上限没有价格就得打电话问销售。

Firecrawl 这一行最容易被误读，值得说清楚。100 万 credit 听起来像 100 万页，做最基础的抓取确实是。一旦加上 JSON 提取，每页就要花 5 个 credit，同样 $749 只能覆盖 20 万页。这不是定价套路，而是真实工作量的真实成本，也意味着你预算里的数字不等于套餐卡片上的数字。

Firecrawl 自己的文档对另一个约束倒是出奇坦白：真正的瓶颈会是并发浏览器数。Free 套餐从 2 个起，Hobby 是 5 个，Standard 25 个，Growth 50 个，Scale 100 个以上。按 100 个并发页面、每个给足 2 秒算，大约是每秒 50 页，一百万页需要约 5.6 小时。这条路可行，但光靠买 credit 越不过这道坎。

Firecrawl 的各档并发上限来自它自己的定价页。

这一选择背后的抓取库比较，请见 Playwright 与 Puppeteer 的网页抓取对比。

ZenRows 用另一种方式解决同一个问题：让重试免费。失败和重试请求不计费，对付难缠目标时是实打实的优势，这类细节值得在你认定更低的标价会赢之前先确认。

选 Apify 替代方案要看哪些标准？

由四个数字决定，其中三个取决于你的工作量，而不是任何厂商。

在这个规模上，功能对照表基本是噪音，因为每家厂商做的核心工作都一样。真正拉开差距的，是当你的抓取量增长一个数量级时，它们的计费方式如何变化，以及它们设的上限是在增长之前还是之后到来。

注意这张表里关于功能的成分有多少。竞争「Apify 替代方案」这个搜索词的厂商，大多在同一张清单上较劲：代理池、JS 渲染、CAPTCHA 处理、集成。这些清单往往趋于一致。计费方式不会趋同，而它才是决定你账单的部分。

Apify 替代方案怎么选？

把答案对应到你的渲染比例和授权状态，候选名单会立刻缩到一行。

1. 静态 HTML、公开数据、一百万页以上。 留在按 CU 计费的平台上，或者自建，把精力花在代理费率和削减页面体积上。在这个渲染比例下换平台，只能省下个位数百分比。
2. 以静态为主，但有一小部分顽固地需要渲染。 把抓取拆开。大部分走便宜的静态请求，剩下的走渲染路径。这是回报最高的一个决定，而且做起来不花钱。
3. 整体重度依赖 JavaScript，数据公开。 如果这类 API 帮你把提取也做了，那它在这里值这个溢价，因为你买的是 Token 和结构化输出，而不只是字节。选套餐之前先为格式倍率留出预算。
4. 目标不友好，经常被封。 为价钱算重试，而不是算请求。不计失败费用的厂商，即便标价更高也可能更便宜。
5. 在登录之后，或内部仪表盘。 别比爬虫价格了。这是需要授权、依赖会话的工作，要在一个已经持有会话的浏览器里跑，这正是 ego (lite) 的用武之地。关于具体机制，可以看我们写的登录墙后的抓取，同时要明确：这里没有任何工具会绕过网站的访问控制。
6. 几百页，频繁刷新。 以上都不适用。你还没到让成本模型变得有意义的量级，无代码工具大概就是正确选择。我们的 AI 网页抓取工具指南正是按这个范围来梳理无代码、API 和 agent-browser 三条路线的。

如果你比较的是托管浏览器基础设施而不是爬虫本身，同样的逻辑要再往下一层：无头浏览器与真实浏览器的对比才决定你的单页成本是否会被渲染主导。

什么情况下值得把 ego (lite) 加进工作流？

静态请求会在这五个具体时刻开始不够用：需要登录、视图只在 JavaScript 下渲染、翻页藏在点击之后、筛选其实是表单、需要过验证步骤。

这五种情况值得点名，因为它们都是静态请求自己无法恢复的。curl 会返回登录页并报告 200。HTML 拿到了，里面却没有那些数据行。第二页确实存在，但要先有一个在请求里永远不会发生的点击。你要的数据在一个表单后面，而不是查询字符串后面。账号要你输入一个验证码，而它躺在你另一个标签页里开着的收件箱中。

遇到这种情况，解决办法不是换一个更大的爬虫，而是把同一套工作流放进一个已经带着会话的浏览器里跑。

为了不让这停留在理论层面，我们用一个任务跑了两条路，并保留了证据。任务是：从 Amazon 搜索结果里取前三个非赞助的鱼油商品，字段包括名称、品牌、价格、评分、评论数和规格。一次通过 ego (lite)，一次用脚本走纯 HTTP。两次都在同一台机器、同一天跑完，下面都有记录。

浏览器路线，一步一步来

浏览器这一遍分四个部分：你交出去的输入、Agent 执行的步骤、遇到它不该独自决定的情况时会发生什么，以及你如何核对结果。下面用一次真实商品搜索逐条说明。

1. 输入。 搜索 URL、一个已经登录的 Amazon 账号，以及一句话描述要采集的字段。ego (lite) 基于 Chromium，会沿用你现有的登录状态、扩展程序和历史记录，所以没有导出 Cookie 这一步，也没有任何地方需要粘贴凭据。ego-browser Skill 与浏览器绑定，随 ego (lite) 一起安装，你在 Agent 的聊天框里输入 /ego-browser 即可启用。

1. 关键步骤。 Agent 会打开自己的 Space，那是一个带蓝色光晕标记的独立窗口，所以它不会操纵你正在用的标签页。在里面，Agent 会导航、对页面做快照以读取结构，并把找到的内容采集下来。这些快照能读到嵌套的 iframe，而依赖渲染的提取通常就栽在这里。

3. 失败恢复。 当运行遇到登录、验证码，或任何它不该独自决定的事情时，它会停下来，把你拉进它的 Space，而不是自行猜测。文档写明的行为在风险更高的一端同样成立：求职申请会在最终提交前等你确认，预订流程会走到支付页然后停下。一个撞上登录墙的爬虫会记一个 200 然后继续跑。这个会来问你。
4. 结果校验。 拿采集到的数据行去对照 Agent 当时实际所在的那个页面，而不是你交给它的 URL。Agent 工作时依据的快照就是证据。这次运行唯一一处真实异常就是在这里浮现的，而这类问题只会出现在渲染过的页面上。

换成纯 HTTP 做同一个任务

下面是诚实的另一半，因为有意思的结果并不是 HTTP 失败了，而是它卡在哪里，以及把它跑通付出了什么代价。

HTTP 这一遍用脚本、不带浏览器跑同一个任务。它最后也跑通了。日志记录了这两条路线之间隔着多少传输层的活。

被挑战的请求就是硬停。但这里大多数 503 并不是挑战，要区分这两者得做一次实验。

重写传输层只是问题的一半，不是终点。接下来，提取器还得针对同一个页面被修正两次。

所以两遍都拿到了这三个商品，差别在于各自为到达终点付出了什么。浏览器这一遍打开一个 Space、读页面，并为它报告的每个值留下一张截图。HTTP 这一遍写了六个脚本，因为指纹不匹配换了 HTTP 客户端，加了一层重试，修了一个赞助检测的 bug，修了一个货币的 bug，最后交出的报告承认它对第一个商品没有任何输出。

这正是按页成本模型看不到的部分。两种做法都不算错，而且那些截图里的 Token 和墙钟计数相差不大，光凭速度并不能分出高下。区别在于时间花在哪里。一条路线花在读页面上，另一条花在搭建和调试那套替代读页面的机器上。

对三个商品来说，那套机器本身就是全部成本，而且收不回本。到了十万页，同样的代码可以无人值守跑上一整天，这笔账就会彻底翻转。

什么时候完全不需要 ego (lite)

纯 HTTP 能覆盖的工作比这类工具讨论所暗示的更多。如果页面把数据放在 HTML 里返回，就直接抓取。如果网站公布了 API，就用 API，因为那是网站本意提供的访问方式，而且它能在改版把选择器打乱时依然存活。如果整个任务就是一次大规模公开抓取，中间没有任何步骤需要会话，那么托管平台或按 credit 计费的 API 在吞吐上会胜过本地浏览器。

还要用正确的尺度看待这个 Amazon 案例。它不能证明 HTTP 不行，因为 HTTP 拿到了数据；也不能证明浏览器很快，因为浏览器那一遍同样花了二十多分钟，而且自己的报告里也记了一次失败。它展示的是两条路线上的时间都花在了哪里。浏览器路线唯一真正的问题来自网站，不是工具；HTTP 路线的问题则全来自它自己。

给一个本来不需要浏览器的工作流加上浏览器，是让抓取任务变得又慢又贵的最常见方式。先检查便宜的那条路线，并留意当目标需要会话时，它会付出什么代价。

自建爬虫还值得吗？

常常值得，原因不是手艺，而是算术：到了这个量级，你付的是队列和调度器，而这两样都是大路货。

Scrapy 和 Playwright 免费、文档齐全，而且无聊得正合生产基础设施该有的样子。如果你的抓取是针对稳定目标的周期性任务，自建流水线能完全省掉平台费，只剩下服务器成本和本来就要付的代理账单。

诚实的另一面是，平台费确实买到了真东西。能处理五种不同失败模式的重试逻辑。不会漂移的调度器。存储、日志，以及不动生产环境就能重跑数据集的能力。团队总是低估这些东西的工程工时成本，因为这些工时出现在某人的日历上，而不是发票上。

一条粗规则：抓取是周期性的、目标稳定，就自建；抓取是探索性的，或者你要抓的网站每隔几周就换个样子，就租用。平台费本质上是一笔变更管理费。

这些方案都会在哪里出问题？

三个地方，而且正是它们把一个干净的成本模型拖成超支。

第一，每家厂商的营销说法都跑在文档前面，而差距最大的地方恰恰是你最需要精确的地方。Bright Data 的 web-scraper 页面声称不限并发，同一页上却不公布价格。那不是我们能证伪的谎言，而是我们无法核实的说法，知道这一点本身更有用。看到任何不限量、企业级或无限之类的措辞，就把它当成去找那个具体数字的信号；如果数字没有公布，就假定上限存在，而且是谈出来的。

第二是反爬保护，它与其说是你买的功能，不如说是你要在其下运行的条件。当每个请求都需要住宅 IP、热会话和重试预算时，更快请求路径带来的效率优势就消失了。我们的模型跑到 $1,300，不是因为哪家厂商在宰客，而是因为目标越难，页面越重、白费的请求越多。

第三点没人会写进对比表：这是公开数据基础设施，这样使用它是你自己的责任。服务条款、robots 指令、GDPR 或 CCPA 下的个人数据，以及网站公开页面与用户私人信息之间的区别，这些问题都和你选哪个工具无关，是独立的问题。便宜的爬虫不会让一次不被允许的抓取变得被允许。我们不是律师，这也不是法律建议，但最便宜的抓取，是你的组织真正能站得住脚的那一次。

常见问题

一百万页最便宜的 Apify 替代方案是哪个？

按公开费率，是自建 Scrapy 流水线配上便宜的代理，因为完全没有平台费。在托管方案里，按 CU 计费、跑 HTTP 请求的平台在原始量级上胜过按 credit 计费的 API。但诚实的答案是，平台选择只占账单的小头：住宅流量 $8/GB，一百万页 50KB 的页面无论谁来抓，带宽都要约 $400。

Firecrawl 是好的 Apify 替代品吗？

如果目标是可直接喂给 LLM 的 markdown 和结构化提取，那答案是肯定的，它更容易预测，输出也帮你省掉一层解析。但如果只是单纯抓取一百万页，它的并发上限会比 credit 余额更早成为约束。Free 套餐允许两个并发浏览器，Scale 套餐 100 个以上，所以吞吐是由套餐而非花费封顶的。

Apify 对失败的请求收费吗？

会，间接地收。不管请求返回了什么，运行期间计算单元照样累积，代理带宽也照样消耗在传输上。一次重试的请求会被计费两次，而第一次什么也没得到。

为什么 Apify 替代方案在规模上往往更贵？

从平台层面说，通常并不更贵。它们显得贵，是因为 credit 倍率不能干净地映射到页数上：一次抓取是 1 个 credit，但 JSON 模式是 5 个，而在以代理为基础的厂商那里，JavaScript 渲染可能是一次普通请求的 10 倍或 25 倍。把标价乘以你实际需要的倍率，差距就会收窄甚至反转。

一百万页都需要浏览器渲染吗？

几乎从不需要全部渲染。一个可用的假设是，90% 的页面能作为静态 HTML 读取，10% 需要 JavaScript，所以我们的模型渲染 10 万页、其余走静态抓取。做预算前先在 1,000 页的样本上测出你的比例，因为它对成本的影响比选哪家厂商都大。

Bright Data 和 Oxylabs 作为 Apify 替代方案怎么样？

当问题就出在代理上时，它们最强。Oxylabs 列出的住宅带宽按量从 $3/GB 降到 $2/GB，明显低于 Apify 的 $8/GB，SERP 价格为每次 unit sequence $0.50 到 $1.35。Bright Data 的 web-scraper 页面不公布价格，只强调一个我们无法核实的不限并发说法，所以请把它当成一份要主动去索取的报价，而不是可以据以规划的既定事实。

这里引用的住宅带宽费率列在 Oxylabs 的定价页。

Bright Data 的套餐在抓取器页面上不公布每 GB 费率，最低起步价见它的定价页。

我可以用 ego (lite) 替代 Apify 吗？

它们覆盖的是不同步骤，所以这与其说是替代，不如说是交接。Apify 负责大规模托管抓取。ego (lite) 是一个免费的 macOS 浏览器，编程 Agent 通过你已登录的会话来驱动它；当某个步骤需要登录、渲染后的视图、点击翻页、表单或验证码时，就用它。如果你的任务是大型公开抓取，中间没有任何步骤需要会话，那么流水线里根本不需要 ego (lite)。

抓取前怎么估算代理带宽？

先抓 1,000 个有代表性的 URL，测量压缩后的响应大小，然后相乘。再加上重试系数：一次成功率 85% 时，一百万目标约等于 115 万到 130 万次请求。按更高的数字做预算，因为页面体积会随反爬保护上升。

在这个量级上，Apify 还是正确选择吗？

有时候是。它的 CU 模型透明，按工作量而不是按行数收费，actor 生态也省掉大量粘合代码。如果你的抓取只有几十万页，代理又来自更便宜的厂商，那平台就不是你的问题。离开它的理由通常集中在 credit 会过期、套餐范围内的并发上限来得比你准备好时更早，或者带宽费率在别处更低。

一百万页最先出问题的是什么？

是预算，不是技术。并发上限和重试计费都有文档、可预测。真正让团队意外的是带宽账单、对需要渲染页面数量的假设，以及抓取中有多少其实是没人要的页面。先修范围，再修厂商。

大多数 Apify 替代方案对比回答的是功能问题。在百万页规模上真正费钱的问题是计费方式，它包含三部分：厂商对什么加倍收费、它的上限在哪里，以及失败请求由谁买单？

Apify 对这些问题回答得不错。它的计算单元是一个干净的工作单位，按浏览页面收费而不是数行数。它控制不了的是你最终会盯着看的那部分账单：$8/GB 的住宅带宽，而且是花在大部分字节都是脚手架的那些页面上。

所以有用的动作不是换平台，而是把抓取裁到真正携带数据的页面上，用比浏览器便宜 20 倍的方式抓取静态的大多数，只渲染那需要渲染的 10%。做到这一点，厂商对比就变成一个可以四舍五入的决定。

爬虫够不到的那些部分，登录后的页面和内部工具就是抓取停止、会话开始的地方。ego (lite) 用已经附带登录状态的会话跑同一套工作流，并在某个步骤需要人时停下来问你。而当一次普通请求已经能返回数据行时，那就是全部答案，别把浏览器带进来。

第一次做百万页抓取时，我们以为贵的是平台。结果答案是带宽。