挑战
你正在构建一个 B2B SaaS 产品. 客户上传公司名称列表. 他们期望返回清晰的记录: 收入范围, 员工人数, 技术栈, 融资轮次, 关键联系人, 最新新闻. 他们期望在几分钟内而非几天内拿到结果. 并且他们期望数据是准确的.
这些数据是存在的. 它们位于 Crunchbase, 公司 About 页面, LinkedIn 公司页面, Google Maps, Glassdoor, 地区商业登记处以及 TechCrunch 档案中. 关键在于如何可靠地获取它们.
每个数据源的崩溃方式都不一样. Crunchbase 使用沉重的客户端应用, 如果怀疑有机器人就会重新渲染. LinkedIn 限制请求频率极度严格, 并且其 DOM 更改速度比你修补选择器的速度还要快 (一篇热门社区帖子基准测试显示, 原生 Python 爬虫在触发反机器人防护前大约只能抓取 50 个个人资料). 公司网站从静态 HTML 到单页应用各不相同, 后者甚至需要完整的浏览器才能显示内容. 地区目录每季度轮换一次布局, 并设置特定国家的封锁. 根据 GroupBWT](https://groupbwt.com/blog/challenges-in-web-scraping/) 的 [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 的顶层 (r.proxy) 返回 proxy id, 这样当你需要会话连续性时, 你的后续调用可以将其作为 proxy:"<id>" 传回以保持同一个出口.
重度 JavaScript 的单页应用. Crunchbase, 类似 LinkedIn 的应用, 甚至中型公司网站都不会从纯 HTTP response 中返回你想要的数据. 它们在客户端渲染. 那就是 Browser: 完整的浏览器执行页面, 运行 JS, 并将渲染后的 HTML, cookie 和屏幕截图返回给你. 像 Single 一样, 它在底层通过 Proxy Finder 路由, 你的系统不需要单独的挑选步骤.
带有验证的混合数据源. 对 FourA API 的每次 request 都接受一个 validate 块. 你可以要求特定的状态码, header 匹配或在主体中进行子字符串匹配. 如果 response 是软失败 (带有 CAPTCHA 的 200 页面, 或空数据壳, 或 "我们很抱歉" 插页), 验证器会拒绝它. 你的流水线随后可以通过 Browser 路由相同的 URL. 这一功能消除了数据丰富过程中最昂贵的错误类别: 将垃圾数据写入数据库的静默失败.
这是一个单源调用的形式:
curl -X POST https://api.foura.ai/api/single \
-H "Authorization: Bearer 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 "Authorization: Bearer pk_live_..." \
-d '{
"url": "https://www.example-saas.com/about",
"unblocker": true
}'
路由逻辑在你自己流水线中. 可靠性在我们的系统中. 你决定哪个数据源使用哪种工具. 我们确保工具真正能够跑通.
结果
在公开测试期间, 我们观察到少数团队从内部爬虫切换到 FourA 路由的流水线. 模式是一致的 (基于我们在测试队列中看到的情况的说明性数字):
- 数据丰富延迟 从每家公司 3 到 6 秒下降到缓存住宅路由上的中位数 1.5 秒以下
- 一旦
validate块在软失败到达数据库之前将其捕获, 静默失败率 (带有空数据的 200 response) 从约 8% 下降到不到 1% - 爬虫维护的工程时间 从 1 到 2 名全职工程师减少到一个通常保持安静的 Slack 频道
- 当
unblocker: true与干净的 proxy id 配合使用时, 受保护目录的首次成功率攀升至 90% 以上
还有一个值得关注的数字: 我们看到首次正确率 (正确的数据, 正确的公司) 落后于首次成功率约四个百分点. 这里的教训不是抓取很困难. 而是你仍然需要根据你实际要求的公司来验证记录 (我们在 为什么你的网络爬虫总是崩溃 中写过这种模式).
真正重要的数字不是 proxy 池的大小或 request 数量. 而是你的数据丰富 endpoint 在第一次尝试时返回正确数据的频率, 以及未来六个月爬虫维护图表的斜率.
核心要点
数据丰富流水线的崩溃是慢动作发生的. 你写的第一个爬虫在星期二看起来还不错. 到了第三个数据源, 你在晚上 11 点修补选择器. 到了第十个, 你背负着与客户群一起增长的维护债务. 到了第二十个, 你已经悄悄地停止引入新的数据源, 因为团队中没人想接手下一个.
瓶颈从来不是数据源. 而是路由: 每次都为每个 URL 选择正确的工具, 正确的 proxy, 正确的验证规则. 构建一次这一层, 将其交给已经能做到这一点的系统, 你的团队就可以把星期二的时间花在产品上, 而不是对选择器损坏进行分类.