一、先把场景写清楚：内容展示、研究回测、实盘风控三套标准
股票行情 API 的选型看起来是在对比供应商，实际上是在对比“你要解决什么问题”。同一套数据对内容站点可能够用，对研究回测可能不够一致，对实盘风控可能不够可用。把场景写清楚，是避免踩坑的第一步。
内容展示更关心覆盖与口径稳定；研究回测更关心历史一致性与可追溯；实盘风控更关心延迟分位数、可用性与断线恢复。只要主场景不明确，你就会在“覆盖 vs 延迟 vs 成本”的权衡里反复摇摆。
二、覆盖怎么比：市场覆盖、品种覆盖与企业行动口径
覆盖不应只看“支持多少股票”。你需要拆成三层：市场（美股/港股/A 股/其他）、品种（股票/ETF/指数/期权等是否同一套口径）、以及企业行动（拆股、分红、合并等）对历史数据的影响是否可解释。
如果你需要跨市场产品，最关键的是符号体系与时区：symbol 的命名是否一致、交易日历是否统一、盘前盘后是否有清晰口径。覆盖越广，越要强调口径，否则你会在跨市场图表与排序里遇到大量“看起来像 bug 的口径差异”。
三、延迟不要只看平均：看 P95/P99、抖动与恢复时间
实盘与风控场景里，平均延迟没有太大意义。你要看尾部：P95/P99 是否稳定、延迟抖动是否会让信号频繁误触发、峰值时段是否出现请求堆积。更关键的是断线恢复：恢复后是否能补洞，补洞后是否能对账。
对 WebSocket 推送同样如此：有没有心跳、重连是否会丢序、是否提供序号或严格递增的时间戳。没有这些细节，实时链路越快越容易在关键时刻制造幽灵信号。
四、协议组合：REST 负责一致性，WS 负责实时流
成熟的行情接入通常是双链路：WebSocket 负责实时流，REST 负责快照、历史与补洞。只提供单一协议也能用，但你会把大量工程成本转移到自己身上：补洞、对账、重试、限流与降级都要自己补齐。
验收协议时建议抓三点：是否能从某个时间戳继续拉取、是否能识别乱序与重复、是否提供明确的错误码与限流策略。能把这些讲清楚的供应商，工程落地会轻很多。
五、历史一致性：同一根 K 线一年后是否还是同一根
研究回测最怕的不是缺数据，而是“你不知道数据有没有被改过”。历史数据是否会回填或修正、修正有没有版本与说明、复权口径是否稳定，这些决定了你的回测是否可复盘。
建议做两类验收：重复拉取对比（隔天/隔周重复拉取同一时间段并对比差异），以及实时落盘回放对账（把实时流落盘回放，与历史接口进行对账）。能对账的历史才是可用的历史。
六、字段口径：价格、成交量、复权、盘前盘后要写成合同
股票数据最常见的坑是字段口径不一致：成交量是手还是股，价格是否包含盘前盘后，前复权/后复权/不复权如何定义，停牌与临停如何处理。口径不一致会让你在指标计算、因子回测与风控告警上出现系统性误差。
更稳的做法是把口径写进内部数据协议：字段定义、时区、交易日历、复权规则、缺失处理、异常处理。供应商只是来源，协议才是你的资产。
七、稳定性与可用性：限流、错误码与降级路径决定线上体验
线上系统的事故往往不是“拿不到数据”，而是“拿到的数据不稳定且不可控”。你需要评估限流策略是否可预期、错误码是否可分类、重试建议是否明确、以及在持续失败时能否自动降级。
降级策略应该前置设计：例如推送异常就降为低频快照，或只保留核心标的更新；并把降级状态同步到前端与告警系统。降级可用，比追求完美实时更重要。
八、成本模型：最贵的不是单价，而是并发与订阅粒度不可预测
成本评估要能算出上限：用户并发、刷新频率、标的数量、历史拉取深度、以及是否需要多机房容灾。很多看似便宜的方案会在并发、限流或商业条款上限制扩容，增长后被迫迁移的代价会更高。
更实用的指标是“单位有效吞吐成本”：在满足延迟与稳定性门槛的前提下，你为每个有效报价付出了多少成本，并且这个成本是否可预测。
九、选型决策树：先定门槛，再比较偏好
选型建议先设置硬门槛：核心市场覆盖、口径稳定、历史一致可对账、峰值 P95 可接受、断线可恢复可补洞、成本可算上限。门槛不过关的供应商直接淘汰，不要进入“功能对比”。
在门槛满足后再比较偏好：你更看重覆盖还是延迟、更看重统一接口还是更看重数据深度、更看重成本还是更看重 SLA。这样决策会更快，也更可复盘。
十、结语：把选型做成工程验收，后续维护成本会大幅下降
2026 的行情数据产品竞争会更激烈，但真正的差异不在营销，而在口径、可用性与可对账能力。把场景写清楚，把内部协议固定下来，用验收脚本与对账机制做决策，你就能在增长、迁移与多供应商容灾时复用同一套流程，而不是每次从零开始踩坑。
十一、验收脚本建议：用自动化把“口径”钉死
为了让选型可复盘，建议把验收拆成三类自动化脚本：快照验收（字段、时区、复权、盘前盘后口径）、历史验收（重复拉取对比、回填修正检测、分红拆股影响）、实时验收（延迟分位数、断线重连、补洞对账）。每类脚本都输出同一份报告格式，便于不同供应商横向对比。
只要把验收做成自动化，你就能在供应商升级、字段变更、或流量增长触发限流时快速复测并定位问题，而不是靠人工排查“到底是谁变了”。这一步会显著降低后续维护成本，也是多供应商容灾能真正落地的前提。
