「行情数据不就是从交易所抓吗，为什么要付钱？」这是自建方案最常见的起点。问题在于，抓数据本身只占整个工作量的一小部分，而剩下那部分会持续消耗工程资源，且永远不会结束。
这篇文章用一组透明的假设，把自建与商用的三年总拥有成本（TCO）算清楚。
自建的真实成本结构
自建方案的成本容易只看到第一项——写采集程序。但完整的成本包含五块：
| 成本项 | 说明 | 是否常被低估 |
|---|---|---|
| 初始开发 | 采集、解析、存储、接口封装 | 否，通常是最先被估算的 |
| 持续维护 | 数据源改版、字段变更、异常修复 | 严重低估 |
| 基础设施 | 服务器、存储、带宽、监控 | 中等 |
| 数据质量 | 对账、补数、异常检测 | 严重低估 |
| 合规与授权 | 数据来源合法性、使用范围 | 最常被忽略 |
其中「持续维护」和「数据质量」是自建方案真正的成本黑洞。原因是：数据源的变更不是一次性事件，而是持续发生的。 交易所调整字段、网页改版、接口加验证、限流策略变化——每一次都需要有人响应。
成本假设
为了让对比有意义，先把假设写清楚。你可以按自己的实际情况替换：
| 参数 | 取值 | 说明 |
|---|---|---|
| 工程师全成本 | $12,000 / 人月 | 含薪资、社保、设备、管理摊销 |
| 初始开发投入 | 2 人 × 6 个月 | 覆盖多市场采集、存储与查询接口 |
| 持续维护投入 | 0.5 人月 / 月 | 数据源变更、故障修复、日常运维 |
| 基础设施 | $1,500 / 月 | 采集节点、存储、带宽、监控 |
| 商用套餐 | $299 / 月 | 全市场实时档位 |
| 接入工作量 | 0.5 人月 | 一次性，对接商用接口 |
三年 TCO 对比
方案 A：自建采集
| 成本项 | 计算 | 三年合计 |
|---|---|---|
| 初始开发 | 2 人月 × 6 个月 × $12,000 | $144,000 |
| 持续维护 | 0.5 × $12,000 × 36 个月 | $216,000 |
| 基础设施 | $1,500 × 36 个月 | $54,000 |
| 合计 | $414,000 |
方案 B：商用 API
| 成本项 | 计算 | 三年合计 |
|---|---|---|
| 订阅费用 | $299 × 36 个月 | $10,764 |
| 接入工作量 | 0.5 人月 × $12,000 | $6,000 |
| 合计 | $16,764 |
三年差额约 $397,000。即使把自建的假设放宽一半——初始开发砍到 1 人 3 个月、维护降到 0.25 人月——自建仍是商用的十倍以上。
需要说明的是：这个对比只算成本，没有计入时间。自建方案意味着你的团队有 6 个月不能做产品功能，这段时间的机会成本可能比省下的订阅费更贵。
自建真正划算的场景
自建并非永远错误。以下情况它可能是对的：
- 需要商用 API 不提供的数据：例如特定小众市场的深度数据、非标准化数据源、独家合作渠道。这是自建最强的理由。
- 极大规模下的单位成本优势：如果你的量级已经到了商用定价的高档区间，且需求高度稳定、技术团队充裕，自建的单位成本可能更低。
- 数据作为核心资产：如果数据本身是你的产品差异化来源（而不是基础设施），自建才有战略意义。
- 极低延迟的极致要求：需要在交易所同机房直连，且延迟预算是微秒级。
注意这些场景的共同点：都不是「省钱」，而是「商用方案做不到」。 如果自建的理由只是省钱，那基本算不过来。
商用 API 真正划算的场景
- 产品早期与验证阶段：用免费套餐零成本跑通流程，验证需求后再付费。
- 需要多市场覆盖：一个接口覆盖股票、外汇、加密、期货、指数、大宗——自建要逐市场攻坚。
- 团队规模小：没有余力养一支专职维护数据管道的团队。
- 需要 SLA 与合规保障：99.99% 可用性承诺、明确的授权范围、可审计的服务记录。
- 上线时间比成本更关键：如果竞争对手先上线，那 6 个月花在采集管道上的时间，就是没有花在产品上的时间。
被忽略的隐性成本：合规
这一项在成本对比里经常被完全忽略，但风险最高。自建采集常见三个合规问题：
- 数据来源授权：公开可访问不等于可以商用。抓取公开页面用于商业产品，授权边界往往不清晰。
- 使用范围限制：部分数据源禁止再分发或用于衍生数据产品。
- 服务条款冲突：绕过限流、验证码或反爬机制可能直接违反服务条款。
商用 API 把这些问题前置解决了——数据授权、使用范围、再分发规则都在服务条款里明确。对面向企业客户的产品来说，这一点往往比成本更重要。
务实的结论：先买，必要时再自建
综合来看，多数团队的合理路径是：
- 起步阶段用商用 API：免费档位验证流程，付费档位支撑生产。
- 把工程资源投在产品上：数据接入是基础设施，不是差异化。
- 只在明确的「商用做不到」场景下自建：且只自建那一部分，其余继续用商用接口。
- 混合方案通常最优：核心独家数据自建，通用市场覆盖用商用 API。
换句话说：用商用 API 买时间，把时间投在真正能形成差异的地方。
常见问题
自建采集真的比商用 API 贵那么多吗？
在多数规模下是的。主要成本不是初始开发，而是持续维护与数据质量保障——数据源变更会持续发生，需要长期投入人力。按本文假设，三年差额约 $397,000。
什么情况下自建是合理的？
当商用 API 无法提供你需要的数据时，例如小众市场、非标准化数据源或独家渠道。如果自建的唯一理由是省钱，通常算不过来。
抓取公开网页数据有什么风险？
公开可访问不等于可以商用。主要风险包括授权边界不清、禁止再分发、以及绕过限流或反爬机制可能违反服务条款。面向企业客户的产品尤其需要明确的数据授权链条。
可以先自建再切商用吗？
技术上可以，但切换成本不低——采集、存储与查询层都要重构。更常见也更稳妥的顺序是先用商用 API 快速上线，只在确认某个数据源是核心差异化时才自建。
混合方案怎么划分边界？
按「是否可替代」划分：通用市场覆盖（股票、外汇、加密等）用商用 API；真正独家的数据源才自建。这样既保留了差异化，又避免了重复维护通用管道。
用开源采集器能省下自建成本吗？
只能省下初始开发，省不掉持续成本。数据源改版、数据质量与合规责任仍然在你这边，而且你还多了一个不熟悉的代码库要维护。把它当成方案 A 的一个起点，而不是方案 B 的替代品。
下一步
先把自建的五项成本列全，再和商用方案对比，通常结论会很明显。更细的方案对比可参考 自建爬虫与商用 API 对比 与 免费与付费行情对比；如果你关心的是「先用免费档验证、再升级」，可查阅 套餐定价 了解各档位的市场覆盖；自建方案如果确实要做，数据管道的设计可参考 行情数据库实践，多市场覆盖范围可看 全球股票行情。