行情数据源如何选？老板应该问哪5个问题

技术同事给你推荐了一个行情数据源，说这个稳定、那个便宜、另一个坑多。你听完能判断吗？

大部分创始人的答案是：不能。

但最终签字付款的是你。数据中心成本通常是一家量化创业公司前三大支出之一——仅次于人力和云服务。更关键的是，数据源选错了，不是多花钱的问题，是策略上线第一天就拿着错误数据做决策，而你三个月后复盘才发现。

不懂技术的创始人，如何做出正确的数据源决策？这篇不是技术教程。是决策框架。

一个决策框架：五个维度，按顺序问

我们观察到，创始人在选型时最容易犯的错误不是"选了错的"，而是只问了一个维度就做决定——通常只问了价格。

价格重要，但它排在第五位。在你问"多少钱"之前，先弄清楚以下四件事。

维度一：覆盖范围——你的策略要哪些市场？

这应该是第一个问题。不是因为覆盖越全越好，而是因为数据源的切换成本远高于订阅费本身。

如果你的策略目前只跑 A 股，那就只看 A 股数据源。但如果你有明确的扩展计划——比如半年内加入港股或加密——选型时就需要评估同一家能否覆盖这些市场。

几个容易被忽略的覆盖细节：

• 美股不只是"美股"。正盘 6.5 小时、盘前 4 小时、盘后 4 小时、夜盘 4.5 小时——合计每天 8.5 小时的非正盘数据。选型时要确认"美股行情"是否包含盘前盘后和夜盘。
• 港股有午休时段。部分数据源在午休期间停止推送或降级为延迟数据。
• 加密是 7×24。如果你用传统金融数据架构去接加密行情，断连重连逻辑会出问题。

你该问的：这个数据源目前覆盖哪些市场？我需要新增市场时，是加一个订阅，还是要重新对接一套新接口？

维度二：数据延迟等级——你要多快的数据？

延迟不是越快越好。更快意味着更贵。关键是匹配策略频率。

用非技术类比：快递。普通件够大多数人用，急件才需要顺丰特快。

行业共识是：大部分创业团队从分钟级起步就够用。毫秒级推送在架构和带宽上的额外成本，只有在策略真的有实时性需求时才值得。

你该问的：你们的数据更新频率是什么？是实时推送还是定时拉取？如果我一开始用分钟级，以后能升级到实时吗？

维度三：技术支持——出问题的时候，找得到人吗？

行情数据是基础设施。基础设施最关键的指标不是功能多少，是出了故障有没有人应。

你不需要懂技术细节，但你该知道对方的技术支持是什么配置。一个可操作的判断方式：让团队里的工程师在选型阶段做三件事。

第一，发一次工单。 随便问一个技术问题——比如"WebSocket 断连后你们的 SDK 会自动重连吗？"看看对方多久回复、回复质量如何。选型阶段的响应速度，通常就是付费后的响应速度。如果试用期工单都要两天才回，凌晨出问题你基本不用指望。

第二，要一份真实的对接时间线。 问对方："跟我们技术栈类似的团队，从注册到跑通第一行数据，通常用多久？"如果对方只能说"很快""很简单"，但拿不出具体案例，说明他们没有真正服务过同类团队。

第三，问清楚支持边界。 "你们的支持范围是接口问题，还是包括集成建议？"有的服务商只负责保证数据推送到端点，连上报文格式变更也不主动通知；有的会帮你排查接入过程中的字段理解偏差、时区转换这类实际问题。等你团队半夜被一个数据异常搞醒时，这两种支持模式的差距会被放大十倍。

你该问的三句话：

• "试用期间我能发工单测你们的响应速度吗？"
• "和我们类似的团队，你们服务过多少家？"
• "如果有字段变动或接口升级，你们怎么通知客户？提前多久？"

维度四：集成难度与工程成本

这个维度对非技术创始人最不直观，但可能是成本最高的坑。

描述一个真实场景（不涉及具体供应商）：

你的工程团队接入了第一个数据源，它用 last_price 表示最新成交价。半年后策略扩展到港股，接入了第二个数据源，同一个字段叫 last_done。再后来加入加密市场，第三个源叫 px。

>

三个名字，同一个东西。你的工程师不得不维护一个适配层，把这些名字统一成同一个内部字段。这段代码不产生任何策略收益、不改善任何因子表现。但它需要被写出来、被测试、被维护。每一个新数据源都在增加这个适配层的复杂度。

你该问的：

• "你们的 API 文档是否完整公开？工程师能在一天之内跑通第一行数据吗？"
• "你们有 GitHub 开源示例代码吗？"
• "如果我从一个市场扩展到多个市场，用的是同一套接口还是需要接新的？"

维度五：定价透明度

价格放到最后问，不是因为它不重要，而是因为没有前四个维度的约束，比价没有意义。

以下是行业内的价格带参考，不指向任何具体供应商：

API 化的统一数据服务是第三个类别中的一个子方向——用一套接口覆盖多个市场，按需付费。以 TickDB 为例：从 Starter（$99/月）到 Enterprise（$899/月），按团队所需的订阅品种数、历史数据年限和请求频率分档，面向开发者和 AI 助手。这种方式适合市场覆盖广、但不需要终端级功能套件的团队。

你该问的：

• "定价是按请求次数、按订阅品种数、还是按月固定？"
• "超额使用是降级服务还是额外扣费？"
• "能不能月付而不是年付？前期验证阶段我不想锁定一年。"

选型前，把这张清单发给候选供应商

对于不做技术决策的创始人，以下 8 个问题比任何代码都更实用：

📋 选型前必问的 8 个问题：

1. 覆盖哪些市场？（A股/港股/美股/加密/外汇/指数）
2. 实时行情是什么延迟等级？（日线/分钟/毫秒）
3. 推送方式是 WebSocket 还是需要我主动轮询？
4. 历史数据能回溯多少年？
5. 技术支持是什么形式？工单响应多久？有没有对接群？
6. 定价模式是什么？超额使用怎么算？
7. 有没有公开的 API 文档和 GitHub 示例？工程师一天能接上吗？
8. 支持哪些支付方式？（对公转账、发票、USDT）

这 8 个问题的答案拉出来，横向对比，比听任何一家销售介绍都更有效。

选型中最典型的一个错误

多数团队选数据源时犯的错不是"选错了"，而是每次只解决眼前的问题。

先买了一个只覆盖 A 股的，半年后策略扩到港股，再接第二个。第二个数据源的字段命名、时区定义、错误码和第一个完全不同，工程师多维护一套适配层。当两个源同时出问题时，两家供应商互相推责任——一个说"我们的数据没问题，是对方影响了你的信号"，另一个说同样的话。你作为老板，听不懂技术细节，也无法判断谁在说谎。

这不是哪家供应商的问题。是在选型之初，没有把未来的市场扩展需求纳入评估维度。

能用一套接口覆盖你未来两到三年可能需要进入的市场，通常比后来一个一个拼凑更划算——不仅省订阅费，更省去了每接入一个新源的适配成本和排查数据冲突的时间成本。TickDB 用一套接口统一覆盖六大市场的数据推送，trade_session 等字段在服务端已完成标准化，面向开发者与 AI 助手——如果团队未来有多市场策略的规划，这个方向值得放进选型池。

"哪家好"没有标准答案

数据源选型没有最优解。

但"我的团队现在需要什么、未来两年可能会需要什么"——这两个问题，你必须先想清楚。

买贵了是浪费。买便宜了，后期迁移成本更高。选了一个只解决当下的，意味着你默许了未来为每一次市场扩展重复支付对接成本。

你的团队现在用什么数据源？选型时踩过什么坑？评论区聊聊——我们会在后续文章中选取有代表性的经验做匿名分享。

📡 数据由 TickDB.ai 提供

通过 TickDB API 获取实时行情数据

一个 API 接入外汇、加密货币、美股、港股、A股、贵金属和全球指数的实时行情。支持 WebSocket 低延迟推送，免费开始使用。