挑战
你正在构建一款 B2B SaaS 产品。你的客户上传了一份公司名称列表。他们期望返回一份清洗好的完整档案：营收区间、人员规模、技术栈、融资轮次、核心联系人、最新动态。他们期望在数分钟而非数天内拿到数据。而且他们要求数据必须准确无误。
这些数据确实存在。它们分布在 Crunchbase、公司关于页面、LinkedIn 公司主页、Google Maps、Glassdoor、区域商业注册库以及 TechCrunch 归档文章中。难点在于如何稳定可靠地获取它们。
每个数据源的报错方式都各不相同。Crunchbase 运行着庞大的客户端应用，一旦怀疑是机器人在访问就会触发重新渲染。LinkedIn 具有极其严格的 rate limit，其 DOM 结构的变动速度远快于你修补选择器的速度（社区一篇热门文章测试显示，原生 Python 爬虫在抓取约 50 个主页后就会被该站点拦截）。公司官网的架构形式多样，从纯静态 HTML 到必须依赖完整浏览器才能渲染内容的单页应用。区域名录每季度都会轮换页面布局，并设置特定国家或地区的访问限制。根据 GroupBWT 的 2026 年行业报告，在某些垂直领域中，有 10% 到 15% 的爬虫每周都需要进行修复，仅为了应对反爬检测机制的更新和 DOM 结构的漂移。
因此，你的数据补充流水线最初设计为包含五个数据源的清晰架构。六个月后，它变成了一团乱麻：充斥着半失效的爬虫、重试队列，以及一个名为 #scraper-alerts 但再也没人愿意打开的 Slack 频道（我们之前曾讨论过自建和维护爬虫的隐形成本）。技术支持队列中关于数据质量的投诉堆积如山。你的团队甚至开始自嘲，公司名字应该改成“五个爬虫与一份祈祷”。
应对方案
暂且抛开具体爬虫不谈。数据补充的核心难点不在于数据提取。而在于调度路由：判断哪个数据源需要哪种工具、哪种 proxy、哪种重试策略，以及什么样的数据才算是一次“成功”的 response。
像 FourA 这样的平台为你提供了三款产品，直接对应你将要处理的三类数据源。
静态 HTML 目录与注册库。 大多数区域商业注册库和许多老牌 B2B 目录都采用服务端渲染。它们只需要来自纯净 IP 的快速、低开销 HTTP request。这就是 Single 的用武之地：输入一个 URL，输出一个 response。加上 unblocker: true，即可绕过足以让原生 HTTP 客户端完全瘫痪的握手级拦截。Single 会自动通过 Proxy Finder 进行路由，并在 response 顶层返回 proxy id（r.proxy），因此你的后续调用可以将其作为 proxy:"<id>" 回传，以便在需要维持会话时固定使用同一个出口节点。
重度依赖 JavaScript 的 SPA。 Crunchbase、LinkedIn 风格的应用，甚至中型公司的网站都不会在常规 HTTP response 中返回你想要的数据。它们在客户端渲染。这正是 Browser 的用武之地：完整的浏览器执行页面、运行 JS，并向你返回渲染后的 HTML、cookie 和截图。与 Single 类似，它在底层通过 Proxy Finder 进行路由，无需你在端侧执行单独的挑选步骤。
带验证的混合数据源。 发送到 FourA API 的每个 request 都支持 validate 块。你可以要求特定的状态码、header 匹配项或 body 中的子字符串匹配项。如果 response 属于软失败（例如返回 200 页面但要求验证、空数据外壳或“很抱歉”插页式提示），验证器会直接拒绝它。随后你的流水线可以将相同的 URL 路由至 Browser。仅凭这一项功能，就能消除数据丰富过程中代价最高的一类 bug：向数据库写入垃圾数据的静默失败。
以下是单数据源调用的结构：
curl -X POST https://api.foura.ai/api/single \
-H "X-API-Key: pk_live_..." \
-d '{
"url": "https://registry.example.com/company/123",
"unblocker": true,
"followRedirects": 5,
"validate": {
"status": { "accept": [200] },
"data": { "fail": ["captcha", "blocked", "access denied"] }
}
}'
以及针对重度依赖 JavaScript 的企业网站的 Browser 等效实现：
curl -X POST https://api.foura.ai/api/browser \
-H "X-API-Key: pk_live_..." \
-d '{
"url": "https://www.example-saas.com/about",
"unblocker": true
}'
路由逻辑位于你自己的流水线中。可靠性则由我们保障。你决定将哪种工具分配给你的哪类数据源。我们确保该工具切实穿透目标。
结果
在公测期间，我们见证了数个团队从自建爬虫切换到基于 FourA 路由的流水线。其表现高度一致（以下数据基于我们在测试群体中观察到的典型情况）：
- 丰富化延迟：在住宅代理缓存路由上，每家公司的处理延迟从 3 到 6 秒降至中位数 1.5 秒以下
- 静默失败率（返回 200 但数据为空）：在
validate逻辑块于软失败写入数据库前将其捕获后，失败率从约 8% 降至 1% 以下 - 爬虫维护耗费的工程时间：从 1 到 2 名全职工程师减少为一个基本保持安静的 Slack 频道
- 受保护目录的首次请求成功率：当
unblocker: true搭配干净的 proxy id 时，成功率攀升至 90% 以上
还有一个值得注意的数据：我们发现首次请求正确率（正确的数据对应正确的公司）比首次请求成功率落后约 4 个百分点。这带来的教训并非数据抓取本身有多难，而是你仍然需要对照实际请求的目标公司来校验记录（我们在 为什么你的网络爬虫总是崩溃 中讨论过该模式）。
真正关键的数据并非 proxy 池规模或 request 请求总量。而是你的数据丰富化 endpoint 首次尝试便返回正确数据的概率，以及未来六个月内爬虫维护成本曲线的走向。
核心结论
数据丰富化流水线的崩溃是一个缓慢的过程。周二刚写好的第一个爬虫运行良好。到了第三个数据源，你不得不在深夜 11 点修补选择器。到了第十个，维护债务已随着客户规模同步膨胀。到了第二十个，团队内部已没人愿意接手新项目，你只能悄悄停止接入新的数据源。
瓶颈从来不在于数据源本身。而在于路由：每一次都为每一个 URL 精准匹配合适的工具、合适的 proxy 以及合适的校验规则。构建好这一层，或是将其交给现成的成熟方案，你的团队就能在周二专注于核心产品，而不是忙于排查选择器失效问题。