每一篇“最佳代理 API”盘点都很容易犯同一个分类错误：它把 Bright Data、Thunderbit 和 Apify 当成了在同一件事上正面竞争的产品。事实并非如此。一个产品可能提供路由后的 IP 连接，另一个可能直接返回结构化 JSON，还有一个则可能运行定时抓取工作流。拿这些产品去比单一的起始价格，就像把花园水管和净水厂放在一起比价一样不合逻辑。
本指南基于 2026 年 8 月 10 日检索到的官方文档，梳理了十款代理、托管抓取、提取与平台类产品。本文不会宣布一个“放之四海而皆准”的赢家，也不会重复那些无法迁移的成功率宣称。相反，它会教你如何定义什么才算有效结果，如何按类别缩小候选范围，以及如何针对你自己的目标开展一轮授权试点。
为什么“代理 API”并不只是一种东西
每次有人问“该选哪个代理 API”时，问题的核心混淆都差不多：这个词至少涵盖四类截然不同的产品。
原始代理网络只给你 IP 和路由控制——请求逻辑、重试、必要时的 JavaScript 渲染，以及返回内容的解析，都还是你自己负责。这最接近教科书意义上的代理： RFC 9110 将其描述为客户端选择使用的消息转发中介，仅此而已。
托管解封或浏览器 API则接管了更多请求生命周期。你只需要提交一个 URL，它会自动选择 IP、按需渲染页面、在失败时重试，并返回 HTML、截图，偶尔也会返回 Markdown。
提取 API再往上一层——你拿到的是结构化 JSON 或干净文本，而不是需要自己解析的原始 HTML。
抓取平台则把以上能力和定时、存储，以及通常会附带的预制爬虫市场打包在一起。
这对“选择代理 API”这类文章为什么重要？很简单：价格和“成功率”在这些类别之间根本无法直接比较。按流量计费的住宅代理网络，和按请求计费的托管 API，本来就在解决不同问题。它们的分母、包含的工作内容和输出语义都不一样，因此只看首页标价会非常误导。所以下面每个产品介绍都会先标明类别。
还有一点要先说清楚：有了代理访问权限，并不代表你就可以随意抓取任何内容。授权、目标站点服务条款和数据隐私义务，是和“哪家供应商 IP 池最大”完全不同的议题。无论代理 API 多强，都无法替你抹掉这些责任。
如何评估这十个选项
不存在一种对所有团队都公平的固定权重。原始 HTML 归档、位置敏感的价格监测、结构化数据补全，这三类工作流的要求完全不同。建议先用下面这些维度，给它们分配总和为 100 的权重，然后只根据你自己的试点结果或明确的书面需求打分：
| 评估维度 | 需要衡量什么 |
|---|---|
| 有效结果率 | 通过语义校验的尝试占比，而不只是 HTTP 200 |
| 每个有效结果的成本 | 请求、流量、渲染、重试、解析、存储和人工操作成本，除以有效输出数 |
| 输出匹配度 | 原始响应、渲染后的 HTML、截图、Markdown，还是符合模式的结构化数据 |
| 连接与地理控制 | 你真正需要的地区、城市、ASN、会话、轮换、请求头、Cookie 和协议控制 |
| 可观测性与限制 | 请求 ID、计费单位头、日志、回放、并发控制和预算停止机制 |
| 合规证据 | 来源说明、合同、目标站点适用性、可审计性与支持流程 |
| 工程投入 | 集成、解析器维护、监控和人工修复所耗费的时间 |
不支持的单元格留空，或者标注“不适用”。目标是做出适合具体工作负载的决定，而不是制造一种虚假的精确感。
1. Thunderbit
Thunderbit 是这份名单里的例外，因为它更像一个邻近的提取 API，而不是你接进 HTTP 客户端的原始代理网络。它公开的 API 文档介绍了用于 Markdown 的 Distill、用于结构化 JSON 的 Extract，以及用于异步 URL 集合的 Batch。若你想要的输出是内容或记录，而不是代理连接，这个边界就能帮你省掉后续好几步。
这种实际差异在你发出请求的那一刻就会显现出来。传统代理 API 的一次成功调用，通常只会返回原始 HTML——等于只完成了一半。使用 Thunderbit 的 POST /extract 端点时，你只需传入目标 URL 和描述所需字段的 JSON Schema，返回结果已经是与该 schema 对应的结构化 JSON。无需编写 CSS 选择器，也不用担心网站在 Q3 重设计商品页后，解析器跟着报废。
这个产品边界的实际价值在于：调用方可以直接描述输出结构，而不是自己维护一套代理、渲染器和解析器链路。不过，这依然需要真实试点。正式采用之前，请先在授权 URL 上验证字段完整性、目标支持情况、延迟、当前单位消耗、并发能力和失败行为。
主要特性：
- 默认输出结构化——返回与你定义的 schema 匹配的 JSON，而不是原始 HTML
- 有文档支持的渲染与路由控制——作为提取端点的一部分进行处理，而不是独立的原始代理产品
- HTTP API 边界清晰——Distill、Extract 和 Batch 分别覆盖 Markdown、结构化 JSON 和异步 URL 集合
- Batch 模式适合处理多个 URL 的异步任务，尤其适用于不止几页的工作量
- Schema 形状的提取可以降低字段级验证和维护负担，但不能完全消除它
计费单位：Distill 和 Extract 使用的是按页计费单位，而不是代理带宽。预算前请查看最新的 Thunderbit 定价 和 API 文档，因为单位和套餐都可能变化。
适合谁：希望开箱即得、可验证的结构化数据，又不想自己搭建和维护“代理轮换 + 解析器”管线的开发者。
传统代理 API 仍然更合适的情况：如果你需要原始 HTML 供自定义管线处理、需要大批量归档，或需要非 HTTP 协议，那么 Thunderbit 的结构化输出模型就不是对口工具——你真正需要的是后面九个选项中的某一个。
跳过代理，直接用 AI 驱动提取 Thunderbit 的智能网页爬虫会自己处理渲染和反爬墙，很多任务根本不需要单独的代理 API。 Get Started Free
2. Bright Data
Bright Data 是这个行业里最接近“老牌巨头”的存在，提供住宅、数据中心、ISP 和移动代理网络，此外还有一个名为 Web Unlocker 的独立托管产品。这里“独立”两个字很关键——Bright Data 不是单一产品，而是一整套家族，具体价格和行为会因你购买的组件不同而有很大差异。
住宅网络文档列出了国家、地区、城市、ZIP 和 ASN 定向能力。Web Unlocker 则是一个独立的托管层，采用按成功付费并设置月度消费上限。这些控制都很有用，但其准确性和适配性仍需在买家自己的试点中验证；本指南并未做跨供应商的地理对比基准测试。
主要特性：
- 提供住宅、数据中心、ISP 和移动代理类型，并支持细粒度地理定位
- Web Unlocker 托管 API，支持按成功付费和消费上限控制
- 住宅 IP 有公开的自愿来源说明
- 提供调试字段（请求 ID、计费状态、对端国家/地区）用于排查问题
计费单位：原始代理产品和 Web Unlocker 的计费单位不同。预算前请务必确认具体产品、承诺条款、目标适用性和当前费率。
适合谁：需要尽可能完整代理类型、并愿意接受更复杂产品线以换取规模化能力的企业团队。
3. Oxylabs
Oxylabs 与 Bright Data 属于同一重量级——同样提供住宅、数据中心、ISP 和移动代理网络，并有单独的 Web Unblocker 产品用于托管访问。它的会话管理使用专门的 X-Oxylabs-Session-Id 头，能在限定时间内保持 IP 连续性，这对分页搜索结果之类的多步骤流程尤其有用。
主要特性：
- 多种代理类型，并带有供应商文档中的地理控制能力
- Web Unblocker 用于 JS 渲染和托管解封，当前定价按 GB 计费
- 通过基于头部的会话 ID 保持会话连续性
- 示例响应中包含作业/会话头，便于调试
计费单位：本次检索到的 Web Unblocker 页面采用按 GB 计费的套餐，并带有与套餐对应的速率限制；Oxylabs 的其他产品则使用不同单位。请以所选产品的最新页面为准。
适合谁：需要大规模、地域多样性强的运营团队，而且不介意在不同产品之间管理基于 GB 的计费方式。
4. ScrapingBee
ScrapingBee 是一个托管 HTML API：你发送 URL，它返回页面内容，而下游验证和解析通常仍由你负责。它的文档公开了一个与功能相关的积分系统、Auto-Mode、费用头，以及可为单次 Auto-Mode 请求设定上限的 max_cost 参数。
主要特性：
- Auto-Mode 会自动升级配置（代理层级、渲染能力），直到请求成功
max_cost参数可限制单次请求开销- 每种 Auto-Mode 组合尝试失败都不扣积分
- 每个响应都带有使用/成本头，方便实时追踪
计费单位：积分会因渲染、代理层级和其他已启用功能而变化。不要把基础套餐当成单次请求价格；应查看当前积分阶梯和并发限制。
适合谁：中小型项目，重视快速上手而不是深度定制——只要你理解了积分规则，成本其实是相当可预测的。
5. ZenRows
ZenRows 将 Universal Scraper API、Scraping Browser 和住宅代理整合在一个平台下，并针对 JavaScript 渲染和高级代理使用设置请求倍数。这里有个值得特别提醒的细节：ZenRows 会把 HTTP 404 和 410 计为“成功”用于计费，这很好地提醒我们——供应商发票里的“成功”，和你验证器里的“成功”，并不是一回事。
主要特性：
- 组合式工具：抓取 API、浏览器自动化和住宅代理
- 声称支持多种输出格式（JSON、Markdown、截图、纯文本）
- 托管渲染与访问组件，需在授权目标上验证当前行为
- 基于 URL 的使用上限，超额前会暂停请求，需额外购买容量
计费单位：按请求积分计费，并针对 JavaScript 渲染、高级代理等功能设置文档化倍数。请确认当前套餐和倍数规则。
适合谁：想从同一供应商评估抓取 API、浏览器和代理产品的团队，同时会在授权目标上分别测试所选产品。
到目前为止，我们能看出什么
看完五款工具后，模式已经很明显：几乎没有哪家产品边界和营销文案完全一致。Bright Data 和 Oxylabs 都把“原始代理”和“托管解封”拆成了不同产品，并采用不同的定价模型，因此供应商官网首页本身并不能回答“我到底要花多少钱”——你得先确定具体产品。ScrapingBee 和 ZenRows 都采用基于积分的计费，并通过倍数机制逐步加价，这比按 GB 计费更透明，但你仍然要仔细阅读哪些功能会触发倍数。
还有一个反复出现的主题是：“成功请求”是供应商定义的，不是你定义的。ZenRows 把 404 也算进可计费成功，并非故意误导，只是定义不一致而已——如果你默认“被计为成功”就意味着“我需要的数据真的已经拿到了”，那就容易踩坑。
6. Scrape.do
Scrape.do 提供托管 Web Scraping API，并采用“成功 API 积分”计费模型——你只会为当前核心端点付费，因为公司自己的定价导航里把独立代理和抓取浏览器产品标注为“即将推出”（如果你以为 Scrape.do 现在已经卖原始代理，最好先确认一下）。它的 API 能力覆盖地理定位、会话、请求头、Cookie，以及浏览器/代理模式切换。
主要特性：
- 基于积分计费，达到月度上限后自动停止请求（默认不会出现意外超额）
- 对符合条件的目标可切换高级网络
- 会话和地理控制能力，应针对具体工作负载进行测试
- 为 JS 密集型页面提供浏览器渲染模式
计费单位：打包的成功 API 积分，并带有月度限制；请核实当前套餐限制、并发能力和额外容量规则。
适合谁：预算敏感、但又不想接受按 GB 计费的团队，希望使用托管 API 完成任务。
7. Smartproxy / Decodo
Smartproxy 已更名为 Decodo，其当前住宅代理定价页记录了按 GB 和即用即付两种方案，并支持 ASN 级定向以及通过 HTTP(S)/SOCKS5 的轮换和粘性会话。检索到的页面把 Proxyway 的研究作为性能声明来源。这个来源信息有参考价值，但并不能证明同样结果会迁移到别的目标、地区、时间窗口或账户配置上。
主要特性：
- 住宅、数据中心、ISP 和移动代理类型
- 支持 ASN 和地理位置级别定向
- 通过 HTTP(S) 和 SOCKS5 提供轮换与粘性会话支持
- 性能声明来自第三方研究，而非厂商自述
计费单位：本次检索到的住宅页面显示按 GB 和即用即付选项。请在所选产品页确认最新费率和包含的控制能力。
适合谁：电商监控和中等规模运营，希望获得较丰富的代理选择，但又不想承担企业级定价。
8. Scrapfly
Scrapfly 是一个托管抓取 API，并带有可选的 Anti Scraping Protection（ASP）功能。其官方文档明确说明，目标站点的防护会持续演进，解封后的恢复时间难以预测，而且资源相关成本也可能变化。这个说明很重要：托管访问并不等于长期稳定访问的保证。
主要特性：
- ASP 会根据目标难度动态提升成本
cost_budget参数与失败抓取公平保护机制（被排除的状态码不会算作你的消耗）- 响应级成本头和请求回放/调试面板
- 可选浏览器渲染和住宅代理池
计费单位：积分，费用会随代理池、渲染和 ASP 配置变化。响应头、cost_budget 和项目限制有助于衡量并控制这部分成本。
适合谁：特别重视反检测工具，并希望清楚看到每次请求到底花了多少积分的团队。
9. Zyte
Zyte（老用户可能还记得它以前叫 Scrapinghub）提供一个 API，可根据请求返回原始 HTTP 响应、浏览器渲染后的 HTML、截图，或自动提取出的结构化对象。定价按目标/请求层级而不是统一费率计算；和这里的几款工具一样，失败响应和被限流的请求通常不收费。
主要特性：
- 多种输出模式：HTTP、浏览器、截图或自动提取
- 与 Scrapy 的原生集成，方便已经在该生态中的 Python 开发者
- 可提前设置消费上限和阻断阈值
- 依据目标/请求层级定价，会随站点难度变化
定价：按需付费可用；具体费率取决于目标层级。
适合谁：需要托管 HTTP/浏览器/提取 API 的团队，尤其是已经在使用 Scrapy 的团队。目标适配性和层级稳定性必须通过试点来确认。
10. Apify
Apify 与其说是代理 API，不如说是一个完整的抓取平台——计算资源、预制 “Actors”（它们对封装爬虫的称呼）、定时任务、数据集存储和代理服务都打包在一起，而且每一项都有单独计费。如果你想要的是常见网站的现成爬虫市场，这很方便；但如果你只是想要一个代理，结果却被整个平台包围，这就会变成一种复杂性。
主要特性：
- 提供常见抓取目标的预制 Actors 市场
- 可作为一个组件使用的住宅、数据中心和 SERP 代理服务
- 支持定时、数据集存储和 Webhook，用于工作流自动化
- 详细的代理诊断状态码，便于排查失败请求
计费单位：预付费平台用量可能包括计算、Actor、代理、数据集和存储的独立费用。建模时应覆盖整个工作负载，而不是只看代理这一项。
适合谁：比起原始代理控制，更看重现成爬虫和工作流自动化的团队。
隐性成本问题：请用“每个有效结果的成本”衡量
标价只是分子的一部分。真正有用的分母不是请求数、传输字节数，也不是 HTTP 200 响应数，而是那些通过你自己的语义验证器的输出数量。
在试点开始前先定义好衡量方式：
cost_per_1,000_valid = total_pilot_cost / valid_results * 1,000
这里的 total_pilot_cost 应包括各候选项之间真正不同的成本：请求或网络单位、渲染和高级路由倍数、重试、解析、计算、存储、监控以及人工时间。valid_results 则应只统计那些字段完整、地区正确、新鲜度可接受、且不是伪装成内容的挑战页或同意页的响应。
可以考虑一个故意设定的假设例子。Provider A 的测试批次花了 3.00 美元，产出 600 条有效记录；Provider B 花了 3.50 美元，产出 950 条。它们归一化后的成本分别是每 1,000 条有效记录 5.00 美元和约 3.68 美元。这个数字只是用来说明计算方法，不代表任何真实供应商、目标类型或防护系统。
对于像 Thunderbit 这样的提取 API，请把“直接拿到结构化数据，而不是原始 HTML”的价值和成本一并考虑进去。对于原始代理，也要把下游解析器和维护工作算进去。两种边界没有谁天然更便宜，答案取决于这项工作实际需要什么输出。
如果你想进一步了解 AI 提取和基于选择器的抓取在底层机制上有什么不同，可以看看我们的 AI 网页抓取 解析。
代理 API vs. AI 抓取 API：你真的需要代理吗？
几乎每一篇讨论这个话题的高排名文章，都默认读者一定需要代理。没有哪篇会质疑这个前提——这其实挺奇怪的，因为现在网上越来越多人问一个更基础的问题：我真的需要原始 HTML 吗，还是我只需要数据？
| 维度 | 传统代理 API | AI 抓取 API（例如 Thunderbit） |
|---|---|---|
| 返回内容 | 需要你自己解析的原始 HTML | 与你的 schema 匹配的结构化 JSON |
| 托管访问行为 | 由你的代理/客户端栈或独立托管产品控制 | 属于提取服务的一部分，并受其文档化限制约束 |
| 解析/提取 | 你自己构建并维护解析器 | AI 按 schema 提取字段 |
| 页面布局变动后的维护 | 你的团队负责选择器和解析器更新 | 服务承担更多提取逻辑，但你的团队仍需验证输出 |
| 适合场景 | 大批量 HTML 归档、自定义管线、小众协议 | 结构化数据、RAG 摄取、潜在客户名单 |
| 集成边界 | 代理端点或供应商 API | Distill、Extract 和 Batch 这类 HTTP 提取端点 |
坦白讲：如果你的管线确实需要原始 HTML、代理级会话控制，或者自定义请求栈，那么传统代理 API 可能就是正确的边界。如果你需要的是结构化商品数据、潜在客户记录，或适合直接进表格/检索管线的搜索结果，那么提取 API 可以把路由、渲染和提取都收进同一个服务边界里。这并不能证明哪种模型绝对更好，但它会让决策框架更清晰。
如果你的目标明确是找潜在客户或结构化记录，而不是原始页面，那么 AI 潜在客户开发 和 AI 销售 两篇指南，展示的就是这类“输出天然就是结构化行”的典型工作流。
先看看你是否真的需要代理 免费套餐每月覆盖 6 个页面——先测试 Thunderbit 内置渲染能否处理你的目标站点，再决定是否购买代理容量。 Get Started Free
合规和来源问题也应该纳入评估
技术可访问性和授权是两回事。试点前，请先明确组织被允许采集哪些 URL、需要哪些数据字段、保留规则、隐私义务、适用的目标条款，以及出现问题时由谁负责升级处理。买了代理订阅，并不会扩大这些权限。
对于住宅网络，请向供应商索取当前的来源与同意文件、目标适用规则、身份验证或 KYC 要求、审计证据，以及当某个 IP 段或目标不可用时的响应流程。厂商的官方声明当然有参考价值，但它们并不等同于独立的供应链审计。
在试点过程中，如有相关性，请记录地区和 ASN 观察结果，但不要因为一次查询就断言整个网络的来源情况。把不一致之处视为需要向供应商和采购团队追问的问题。一旦授权发生变化、政策检查失败、重试上限达到，或者预算上限触发，就应立即停止运行。
对于提取与平台类服务，来源和访问责任并不会消失，只是被移到了另一个服务边界之后。采购方仍然应该审查合同、可支持用途政策、失败行为和数据处理方式。本文只是技术评估建议，不构成法律意见。
一眼看懂的对比
| 工具 | 产品边界 | 常见输出 | 需要核实的计费单位 | 值得在试点中验证的问题 |
|---|---|---|---|---|
| Thunderbit | 提取 API | Markdown 或结构化 JSON | 按页单位 | 所需字段在不同目标模板下是否仍然有效？ |
| Bright Data | 原始代理家族 + 托管 Unlocker | 连接、原始内容或托管输出 | 流量或成功请求，视产品而定 | 具体是哪一款产品，工作负载需要哪些地理控制？ |
| Oxylabs | 代理家族 + Web Unblocker 和抓取 API | 连接或托管内容 | 依产品而定；检索到的 Unlocker 页面按 GB 计费 | 响应大小和会话连续性会怎样影响成本？ |
| ScrapingBee | 托管 HTML API | HTML | 与功能相关的积分 | 哪种配置能成功，它的每个有效页面成本是多少？ |
| ZenRows | 抓取 API、浏览器和住宅代理 | 多种厂商文档化格式 | 按请求并带功能倍数 | 404/410 计费语义会如何影响你的验证器？ |
| Scrape.do | 托管 Web 抓取 API | 页面内容 | 成功 API 积分 | 高级、地理、会话和浏览器控制是否适配该工作负载？ |
| Decodo | 代理和抓取产品家族 | 连接或产品特定输出 | 本次检索页面显示为 GB 或 PAYG | 位置、ASN、协议和粘性会话控制是否足够准确？ |
| Scrapfly | 托管抓取 API | 页面内容、浏览器输出、可选提取 | 与功能相关的积分 | 成本预算、日志和失败保护是否按预期工作？ |
| Zyte | 托管 HTTP、浏览器、提取和 Scrapy 接口 | HTTP、渲染 HTML、截图或对象 | 目标/请求层级加选项 | 层级是否稳定，请求模式限制是否适合实现？ |
| Apify | 抓取平台与市场 + 代理 | Actor 或爬虫数据集 | 计算、Actor、代理、存储和数据集费用 | 这个工作流是否真的值得付出整个平台成本？ |
上表中的类别和计费单位，均来自 2026 年 8 月 10 日检索到的官方页面。套餐、限制、名称和功能倍数都可能变化，因此预算前务必再次确认具体产品。
决策流程图：你到底在抓什么？
代理相关论坛帖里最常见的问题，通常是某种变体的“我不知道哪个最好，有没有推荐？”——然后跟着一长串泛泛而谈的清单，但并没有真正回答问题。下面尝试给出一个更接近真实决策路径的版本。
你需要什么输出？
- 需要代理协议控制、原始响应、自定义请求头，或者自己写解析器？优先考虑原始代理产品。
- 需要渲染后的 HTML，但不想自己操作浏览器和重试层？优先考虑托管抓取或浏览器 API。
- 需要验证过的字段、记录或 Markdown？优先考虑提取 API，包括 Thunderbit 文档中的 Distill 和 Extract 端点。
- 需要定时、存储、市场任务和团队协作？优先考虑抓取平台。
哪些控制是不可妥协的？ 把必须支持的地区、会话时长、轮换行为、请求方法、Cookie、请求头、渲染、截图、数据结构、并发、日志和预算停止条件一一写下来。先剔除那些无法满足硬性要求的候选，再去比较软性偏好。
我们的规模到底有多大？ 不要靠一个通用的页面数量阈值来选供应商。规模会和响应大小、并发、功能倍数、有效结果率、谈判条款以及工程投入共同作用。应按预期的目标模板组合建模，并在有代表性的并发水平下跑一次试点。
原始 HTML 还是结构化数据？ 这始终是最关键的分叉点。如果你需要原始 HTML 进入自定义管线，就测试代理或托管 HTML 产品。如果你的交付物是验证过的行、JSON 或 Markdown，那就把提取边界当成独立类别来测试，而不是强行和代理做一对一比较。
建立你自己的加权评分卡
功能列表本身并不能帮你做决定，因为性能和成本取决于目标集合与具体配置。评分卡应该基于你自己的需求和试点结果来建立。下面的权重刻意留空。
| 评估维度 | 你的权重 | 供应商 A 得分（1–5） | 证据 | 供应商 B 得分（1–5） | 证据 |
|---|---|---|---|---|---|
| 有效结果率 | |||||
| 每个有效结果的成本 | |||||
| 输出匹配度 | |||||
| 地理/会话/请求控制 | |||||
| 可观测性与预算控制 | |||||
| 合规与来源证据 | |||||
| 支持与运营适配度 | |||||
| 工程与维护投入 | |||||
| 合计 | 100 |
只有在有证据时才给 1–5 分。请把“不适用”和 0 分区分开。把权重和结果一起公开，方便同事看清楚哪些假设影响了最终结论。
下面这个简洁的 Python 示例会在输入缺失或无效时直接失败。30 次尝试的最低要求只是本文教程里的安全下限，并不是通用的统计样本量断言：
from dataclasses import dataclass
@dataclass(frozen=True)
class PilotResult:
attempts: int
valid_results: int
request_cost: float
engineering_cost: float = 0.0
def cost_per_1000_valid(self) -> float:
if self.attempts < 30:
raise ValueError("pilot needs at least 30 attempts for this tutorial")
if not 0 < self.valid_results <= self.attempts:
raise ValueError("valid_results must be between 1 and attempts")
if self.request_cost < 0 or self.engineering_cost < 0:
raise ValueError("costs cannot be negative")
total = self.request_cost + self.engineering_cost
return total / self.valid_results * 1000
def weighted_score(weights: dict[str, float], scores: dict[str, float]) -> float:
if set(weights) != set(scores):
raise ValueError("every weighted criterion needs a score")
if abs(sum(weights.values()) - 100.0) > 1e-9:
raise ValueError("weights must sum to 100")
if any(not 1 <= score <= 5 for score in scores.values()):
raise ValueError("scores must be in the 1–5 range")
return sum(weights[name] * scores[name] for name in weights) / 100
至少在固定条件下于不同时段跑两轮。每次尝试都要记录目标组、地区、配置、状态、语义验证结果、延迟、重试次数、计费单位、字节数、请求或作业 ID，以及无效原因。更大规模的采购需要一个与团队风险和目标多样性相匹配的样本量；教程里的最低门槛无法替代正式设计。
如果你刚接触抓取，想先打好基础再看供应商对比，可以先读一读我们关于 什么是网页抓取 的入门文章，以及 无需编码的网页抓取 指南。
选择代理 API，本质上不是在问“哪家供应商最好”，而是在问“哪个产品边界最符合我的输出需求”，然后再通过试点验证厂商宣传是否能在你的真实目标上成立。十家供应商、四种产品类别，再加上一条公式（每个有效结果的成本），基本就能把问题解决大半。最后一步很简单：自己跑测试，而不是依赖别人的基准数据。
如果你的真正目标是结构化数据，而不是一堆要解析的 HTML，那么你也可以把 Thunderbit 的 Chrome 扩展 或 API 纳入候选名单，并在试点前查看当前试用或套餐限制。Thunderbit YouTube 频道 也提供了产品演示；请把它们当作演示，而不是独立的基准证据。
试试 Thunderbit 的智能网页爬虫 Get Started Free
了解更多
常见问题
1. 代理网络和抓取 API 的真正区别是什么？
原始代理网络只给你 IP 和路由控制——渲染、重试和解析仍需你自己处理。抓取 API（无论是托管型还是 AI 型）会接管更多生命周期，并根据产品返回 HTML、JSON 或 Markdown。二者不可直接互换，单纯比价格通常会得出误导性的结论。
2. 怎样衡量才算真正有意义的“成功率”？
不要把 HTTP 200 当成功。应该把“我真正需要的内容或字段已经出现且正确”定义为成功，然后用真实目标站点的代表性样本来测试，而不是只看供应商的演示站。
3. 怎样计算每个成功请求的成本？
用你在具体目标上的实际成功率，去除列表价格（按请求或按 GB 计）。一个更便宜但成功率更低的供应商，算上重试后很可能反而更贵——在签套餐前先把账算清楚。
4. 如果我只想要结构化数据，不想要原始 HTML，还需要代理 API 吗？
不一定。像 Thunderbit 这样的提取 API 可以返回结构化 JSON，并把渲染和路由放在服务边界之内，这样你的工作流可能就不需要再单独购买原始代理了。不过，仍然需要测试目标支持和字段有效性。如果你需要的是原始响应或代理级控制，传统代理产品仍然是对应类别。
5. 注册前我应该向供应商询问哪些 IP 来源问题？
请询问当前住宅 IP 的同意和来源文档、支持用途政策、合规证据、可审计性，以及当某个子网或目标不可用时的处理流程。如果风险足够高，应由采购或法务审核这些第一方声明；它们并不等同于独立的供应链审计。
