1. 先别急着对比接口先想清楚这笔行情数据到底要喂给谁做 A 股量化的人几乎没有谁能绕开“行情数据从哪来”这个问题。我自己最早写策略的时候图省事直接从网上抄了一段拉数据的脚本当时跑起来还挺顺结果后来换到 backtrader 做多股回测问题一波接一波停牌股的数据在时间轴上是空的、除权日价格跳了个大坑、复权因子根本没对齐回测出来的年化收益比我实际跑出来的高了一倍都不止。那一次我算彻底明白了选行情 API 这事绝不能只看“能不能把 K 线拉下来”而是要看它能不能撑住你的策略。这也是我把题目定为“选择 A 股行情 API 前先核对这 10 个问题”的原因。无论你是刚开始学着用 backtrader 做多股回测还是自己在写一个 A 股向量回测引擎甚至只是每天想拿收盘数据做个复盘表格这些问题几乎全部命中。你或许觉得自己只是拿个免费接口至于这么较真吗但事实是数据接口的坑专坑新手等你发现策略跑出来的结果全是噪声时往往已经搭进去好几个星期了。这篇文章不打算给你推荐某个具体的 API也没有哪个 API 能通吃所有场景。我写的是 10 个核对问题你可以把这篇文章当成一张“验收清单”拿到任何一个行情服务先按这 10 条过一遍能过几条、卡在哪几条心里大概就有底了。清单之外我还会结合自己实际做 backtrader 多股回测和向量化回测引擎的经历聊聊不同场景对数据的要求差异以及一些你大概率会踩到的坑。2. 数据范围、延迟与历史深度这 3 个问题决定 API 能不能当主数据源2.1 问题一你到底需要覆盖多少只标的多了会怎样很多人一开始只回测一只票比如贵州茅台或者宁德时代觉得任何接口都够用。但一旦你想做全市场选股覆盖范围立刻变成硬指标。A 股现在沪深京三个交易所加起来股票数量超过五千只如果算上各类指数、ETF、可转债标的总数还要往上走。市面上很多免费接口股票代码是写死的或者只覆盖沪深主板创业板、科创板、北交所标的不全。你拉数据时看不出来但一跑全市场选股代码里全是空洞一只股票缺失一天数据在你复权处理时就会产生一个错位最后统计出来的结果会非常难看。我建议你把“计划覆盖的证券类型”写下来然后逐类验证。比如股票沪深主板、创业板、科创板、北交所是否都覆盖指数上证指数、深证成指、沪深300、中证500、中证1000、行业指数衍生品类ETF、可转债、期货主连板块/概念行业板块、概念板块的历史成分和每日行情每类标的选一两个代表拉到最近一年的数据数一数 K 线根数是否和实际交易日基本吻合。普通股票一年大约有 240 多个交易日如果某个标的拉出来的数据只有 100 多根说明覆盖有缺口赶紧换。2.2 问题二延迟模式——实时推送、盘中快照还是收盘后用日线这是很多人忽略的问题。所谓行情 API其实分成几种完全不同的产品形态它们之间的差别比想象中大得多。实时推送型通过 WebSocket 或私有协议持续推送 tick 数据或逐笔成交常用于高频交易或盘口监控。准实时快照型每隔几秒或几十秒拉一次最新快照含最新价、买卖五档、成交额等适合盘中盯盘和准实时信号。日线/历史型提供已经收盘的日线、周线、分钟线回测和复盘主要用这类。做 backtrader 多股回测时你需要的其实是历史型数据。但麻烦在于不少免费 API 是“快照型”的按天返回的数据其实是当天快照的某种聚合不一定按交易所正式行情文件的逻辑生成。你拿它做回测遇到分红除权、涨跌停、临时停牌数据很容易出问题。我的判断标准很简单如果只做日线级别的多股回测优先找专门提供历史 K 线的服务商而不是拿盘中快照接口凑合。盘中快照接口在回测里没有太大价值反倒可能因为字段定义不清楚把成交量、成交额搞错。2.3 问题三历史K线的周期与复权处理方式是否符合回测逻辑日线、周线、月线、60 分钟、30 分钟、5 分钟、1 分钟……不同策略需要不同周期的数据这是第一个维度按需确认即可。更关键的是复权问题。复权分为前复权、后复权和不复权。我的建议是回测一定要用后复权数据。前复权数据把最新价格当作基准历史价格会不断变化你保存好的数据隔一段时间就“漂移”了导致回测结果无法复现。后复权以最早上市日为基准价格序列是稳定的因子计算和收益计算都更可靠。但这里有一个坑很多 API 返回的“复权因子”字段是独立计算的和 K 线数据分属两个接口。你把 K 线和复权因子分别拉下来需要自己对齐除权除息日。对齐不好回测时一个除权日就造成一个模拟的 -30% 收益策略直接崩溃。还有部分免费接口的复权数据只做了“比例复权”没有考虑现金分红的影响长期收益曲线会失真。你可以拿一只长期高分红的股票验证一下比如工行这些把后复权收益和真实收益对比一下就知道接口的复权逻辑是不是完整了。3. 数据质量、频率限制与合规边界这 4 个问题决定数据能不能用来量化3.1 问题四除权除息、停牌、涨跌停这些特殊日期的数据怎么处理数据质量不是看“大部分数据对不对”而是看“极端情况处理得好不好”。A 股有几个非常典型的数据坑除权除息日当天价格会跳空不复权数据必须保留原样复权数据必须正确调整。有的接口在除权日返回的价格和成交量明显异常尤其是成交量有些会在复权算法里被错误缩放。停牌日A 股停牌时没有交易数据有的 API 会返回空值有的会返回上一交易日的价格有的干脆把停牌期间从时间轴里去掉。backtrader 要求每个交易日的时间轴是连续的如果停牌日直接消失就会把后续 K 线的日期错误对齐。我的经验是宁可让它返回 NaN也不要让它返回 0 或者删除该行因为 0 和一个不存在的交易日在回测里同样致命。涨跌停日某些 API 会返回涨跌停价附近的数据但涨跌停当天成交量可能极低或者根本没有成交这会影响你的流动性过滤模块。这些问题很难从接口说明文档里看出来只有用真实案例去查。我建议你从历史数据里挑几个极端日子来核对比如某只股票除权日、某只股票长期停牌复牌日、某只股票连续涨停日分别对比另一个独立数据源看看两个数据源之间有多少偏差。3.2 问题五请求频率限制和配额机制到底有多严格做 over 单只股票的回测很多时候只需要一次性批量拉历史数据频率限制的杀伤力还不明显。但做多股回测时你需要一次性拉全市场几千只股票的数据如果接口限制每分钟 100 次请求每只股票还得分多个周期拉这个速度你能接受吗我在做 A 股向量回测引擎时就遇到这种问题。向量化引擎的优势在于并行计算但数据加载是瓶颈一次性拉完数据可能需要几小时。更难受的是不少 API 会在你请求量达到某个阈值后返回的不是限流提示而是直接给你降级数据比如返回缓存数据、延迟数据甚至返回 200 状态码但 body 里是错误信息。这种隐形限流比显式限流更坑。选型前务必要核对清楚三件事单次请求能返回多少个标的有的接口支持一次请求返回多只股票的历史数据有的只支持单只批量拉取效率差别很大。每分钟/每天的总请求数上限是多少免费档和付费档差距通常非常大。达到上限后的行为是什么是明确的 429还是悄悄降级还是直接封禁一段时间。3.3 问题六数据来源授权与合规边界这是底线问题严格来说A 股行情数据的原始版权在交易所手里。第三方数据提供商需要获得授权才能再分发。普通个人开发者使用免费接口通常处于一个灰色地带接口能用但不代表你有权把数据存储、转发或商用。这一点我必须说透。如果你只是自己写点小策略自娱自乐问题不大各家用各家的。但如果你的项目要给别人用或者你把爬取的数据放在了公开项目里注意“东方股吧反爬”这类问题并不仅仅是技术对抗背后是数据版权和合规风险。公开的行情数据接口其运营方往往明令禁止批量下载、存储和再分发一旦被识别出来账号被清、IP 被封都很常见。我的建议是个人学习和策略原型阶段用免费接口完全没问题但不要大规模抓取并公开分享如果真到实盘或商业化阶段直接买一家有交易所授权的服务商这部分费用在整体成本里其实占比不高但能让你睡得安稳。3.4 问题七可用性 SLA 和接口稳定性如何行情 API 只有在你用它的时候才出问题而这个“时候”往往是关键时候。以前我跑回测时遇到过某天下午接口超时脚本重试时又触发了限流结果整体数据多了一个缺口为了补齐数据又花了一个晚上。这种经历一次就够了。稳定性很难从接口文档里看出来你需要自己做检测。我常用的检测方法很简单连续几天在固定时间点调用同一组接口记录响应耗时的平均值、最大值和失败率。如果连续一周内失败率超过 1%那就要谨慎考虑了。还要注意不同时段的表现差异。很多服务商在开盘时段压力巨大盘中接口偶发超时是正常的但如果是收盘后批量拉历史数据还频繁超时或者连接被重置那基本可以断定技术实力一般。3.5 问题八SDK、文档和示例代码是否真的友好这个问题看似不硬核但在我实际使用中文档好坏决定了你能不能快速上手也决定了后续调试的天坑数量。好的文档应该给你完整的代码示例包含认证方式、请求格式、返回字段说明和错误码表。坏的文档则是一段示例代码跑了直接报错去社区一问才发现是接口早就升级了。我的建议是在选择之前试着用你熟悉的语言Python 最佳调用最小接口取一只股票最近 30 天的日 K 线看几步是否能跑通。在这过程中重点观察认证方式是否复杂需要几层签名返回格式是否规范JSON 结构是否稳定不同标的、不同周期的返回结构是否一致错误码是否清晰字段缺失、数据不完整、限流、参数错误分别是什么表现版本兼容性你保存的数据过几个月再用解析代码还能不能跑如果连“拉 30 天 K 线”这一步都要折腾半天后面的事情只会更费劲。4. 协议格式、成本账与向量化引擎的特殊需求最后 3 个问题的实战视角4.1 问题九HTTP、WebSocket 还是本地文件传输方式影响架构现在行情 API 的传输方式五花八门常见的有 HTTP REST、WebSocket、FTP 文件下载、私有二进制协议。对于回测来说我的建议非常明确回测优先选用能拿到静态文件的接口。如果你要本地做向量化回测比如我用到的 A 股向量回测引擎本质上是在本地内存里做 pandas 或 NumPy 数组运算数据最好能一次性加载到 DataFrame 里。通过 HTTP 一个一个地拉数据再拼接成 DataFrame性能损耗非常大。相比之下服务商提供的历史数据打包下载文件比如按日更新的全市场日 K 线文件在本地做增量更新整体效率会高很多。如果你做的是盘中实盘信号那就需要 WebSocket 或轮询快照这时候你要考虑的就不是“历史序列是否对齐”而是“推送连续性和断线重连”的问题了。这个需求和回测完全不一样不要在选型时把所有需求混在一起。4.2 问题十免费额度与付费成本的真实账本很多人以为免费接口就是“免费”其实免费额度往往是某种意义上的“陷阱”。我做过一个测算如果每天拉一次全市场约 5500 只股票的日线数据按一个典型免费 API 每分钟 200 次的速率限制大概需要半小时左右的请求时间而且这个用量已经逼近不少免费档的“日请求总量”红线。一旦你的回测策略需要多次重复拉取不同周期的历史数据或者每隔一段时间全量更新一次很容易就会触发封禁。付费服务的价格差异很大。便宜的按请求次数计费适合个人策略研究贵一点的按流量包或机柜式服务打包售卖适合团队持续拉取和存储。计算成本时不要只算每月的订阅费还要算运行时间成本和维护成本。一个每天拉数据时都要绕过限流的接口就算免费你的时间也不免费。我个人的建议是个人玩票阶段可以使用免费额度但一旦策略进入持续的日常回测流程就应当考虑付费方案。付费带来的不仅有更高的配额还有更稳定的数据质量和服务支持这笔钱省下来往往会在别处以更难受的方式花出去。4.3 backtrader 多股回测里数据接口选型要额外关注什么如果你主要是用 backtrader 做多股回测有几个和框架强相关的点必须纳入选型逻辑。第一backtrader 的 data feed 是逐个标的喂进去的。你拉数据时最好按标的整理每个标的一个独立的 DataFrame而不是全市场揉在一起。选型时优先选择能方便地按标的导出数据的 API。第二backtrader 默认使用 pandas DataFrame会对索引进行排序和日期对齐。如果数据自带的时间戳是字符串需要先转换如果时间轴里混入了非交易日backtrader 会直接报错或者更糟产生错位。所以你的数据源必须能稳定地剔除非交易日。第三多股回测里同一时间轴上的不同标的需要有相同的日期集合。不同 API 的交易日历可能不同尤其当股票和 ETF 混在一起时必须统一处理。我的做法是单独拉取一份交易日历数据用它做索引对齐而不是信任标的自身的日期序列。这样不管接口给的是多还是少都不会引起后面对齐错误。4.4 向量化回测引擎对行情 API 的要求比你想的更苛刻我自己写过一版轻量级向量化回测引擎用 pandas 和 NumPy 做全市场的批量运算。这个引擎一旦跑起来对行情数据的依赖方式完全不同。向量化引擎需要把全市场的数据拼成一个大三维数组标的 × 时间 × 字段或者至少是多个对齐后的二维序列。这带来两个硬指标一是所有标的时间轴必须完全对齐二是数据必须以“一次加载、全量计算”的方式存取而不是按标的反复读接口。为了满足这个需求最好的方案不是用实时 API而是维护一份本地数据仓库。每天收盘后做一次增量更新更新完成后生成一份统一格式的 parquet 或 HDF5 文件。回测时只读本地文件完全不上网请求。这样你选择行情 API 时关注的重点就变成了它能否方便地支持全市场历史数据的批量导出有没有增量更新的能力。5. 再说说“东方股吧反爬”这件事以及为什么不建议把爬虫当成数据方案5.1 反爬对抗的隐性成本远比想象中大在 A 股数据圈“东方股吧反爬”这类话题经常被拿出来讨论。很多人觉得既然别人能爬我也能爬数据不就免费了吗这个逻辑一开始看起来成立但实际操作后你会发现维护爬虫的代价远超预期。反爬对抗是一种动态博弈。最简单的应对手段是识别请求频率和 User-Agent再进一步会要求登录 Cookie紧接着是验证码、JS 加密、参数签名甚至风控模型识别行为模式。你第一次爬通关可能只花半天但对方改一次加密算法你的解析代码就要跟着改不稳定的数据流直接伤害回测的可复现性。更现实的问题是爬虫抓到的数据结构往往不规范页面里同一种字段在不同页面上有不同单位换个标的就换了单位格式这种数据处理成本比你想象的更高。与其投入大量时间在对抗上不如把这个时间花在策略本身。5.2 更稳的替代尽量用结构化的正式数据源我的态度一直是行情数据尽量不用爬虫除非你有极其特殊的需求。做量化稳定性和可复现性是基本前提而爬虫在稳定性上先天不足。现在市面上已经有大量正规的 A 股行情 API 服务数据来自交易所授权或者是与数据源建立了合作关系无论从字段完整性还是数据质量上都要远远好于爬虫。选择服务商时你可以优先看它的数据来源、授权层级、服务稳定性。用两个月的数据获取和解析成本去对比这个差价很快就能被数据质量差距抵消掉。另外补充一句针对“东方股吧”这类平台它的反爬机制我在技术上看过思路比较先进比如动态加载、行为检测、频率分析和指纹识别常规爬虫硬碰硬很难持续拿到数据。真正要做股吧文本情绪分析的时候更好的路径是购买合规数据或者选择官方提供的开放接口而不是去和风控系统硬扛。5.3 附一张 10 个问题的打分模板拿去直接对照说了这么多最后给你整理一个可以直接拿来用的模板。每接触一个新 API按表打分结果一目了然。打分维度按重要程度加权你可以根据自己的使用场景调整权重。序号核对问题核心关注点我的打分建议1覆盖范围股票/指数/ETF全不全全市场 5000 标的可用2延迟模式实时/快照/日线回测选历史日线型3历史深度与复权周期全、复权因子对有独立后复权字段最佳4数据质量除权/停牌/涨跌停需抽极端日期比对5频率限制每分钟/每日配额满足 10 分钟批量拉完全市场6合规授权数据来源可追溯优先有牌照的服务商7稳定性失败率、耗时波动一周内失败率 1%8文档与SDK上手速度30 分钟内跑通最小示例9传输方式HTTP/WebSocket/文件回测偏爱文件批量导出10成本模型免费/付费带宽不影响长期使用的预算内你把这 10 个问题做完基本就能判断一个行情 API 值不值得进入你的数据栈。不要指望每个问题都拿满分我的经验是回测场景里第 4、第 5、第 7 这三项的权重应该最高如果这三项过关剩下的小问题都可以通过适配代码绕过去。6. 一些踩坑后的补充给数据接入加一层保险最后再分享几个我在实际项目里总结的小经验。第一个经验是关于数据缓存的。不管用哪家 API我都会在本地维护一份原始数据备份每天增量更新绝不直接在 API 的返回结果上做回测。这样即使接口某一天完全挂掉我的回测流程也不受影响数据仓库的更新时间被推迟一天而已。你可以简单理解成“数据双写”一份给 API 实时拉一份留做本地归档。第二个经验是校验要常态化。不要只在首次接入时核对数据最好每次批量更新后都做一次简单校验比如检查每只股票的交易日数量是否一致、最新日期是否等于预期、字段是否包含空值。这个校验脚本可以写得很简单十几行代码就能搞定但能及时发现数据源的隐性变化。第三个经验是不要把文档里写的字段当成全部真相。我遇到过接口文档上写“成交量单位为手”实际返回的却是股最小单位差了一百倍。也遇到过“复权因子”字段返回的是累乘因子而不是单次因子换一种理解方式结果完全不一样。所以每次拿到新字段先用一段已知行情的数据做交叉验证确认无误后再放进正式流程。说到底行情 API 只是一个工具真正决定你策略质量的是你对数据本身的理解和掌控。这 10 个问题看起来繁琐但花一个下午把所有细节核对清楚之后你在写策略、跑回测、上实盘时就不会再被底层数据的坑牵制精力。行情数据是量化的地基地基稳了上面的楼才盖得住。