1. 合集第二篇这次补上的三类数据是短线策略真正缺的东西做财经指标API接口合集这个系列第一篇文章发布之后很多朋友私信我说接口清单确实有帮助但真到自己动手写策略的时候还是有几个坎过不去分钟数据到底怎么拉才算全、买卖五档数据用哪种方式拿才实时、竞价数据要抓哪些字段才有用。这些问题不解决接口文档写得再清楚也只是纸上谈兵。这篇就专门把分钟数据、买卖五档和竞价数据这三类拆开讲。这三类数据放在一起看很有意思分钟数据是回测和盘中策略的地基买卖五档是实时盘口观察的核心竞价数据则是开盘前判断情绪的重要参考。把它们串起来基本就是一套“盘前看竞价、盘中看五档、盘后和回测看分钟K线”的完整数据闭环。内容上我会直接给可运行的代码样例也会把我实际踩过的坑一并写出来。不管你是刚接触接口对接的初学者还是已经在写策略的老手这篇都值得花几分钟翻一遍。1.1 上一篇里大家问得最多的问题第一篇把常用接口按功能分了类行情快照、历史K线、财务指标、资金流向。当时评论区里高频出现的问题有三个一是K线接口只能拿到日线做日内策略完全没有分钟数据可用二是五档行情不知道哪家稳定怕拿到的是延时数据三是竞价数据完全不知道从哪个接口取只能在行情软件里肉眼盯盘。这些问题说到底是同一个核心大家需要的不是更多的接口地址而是怎么把数据正确、稳定地拿回来并落地使用。所以这期我改变了写作方式不再铺开列表而是把三类数据逐个做深度拆解从接口设计到本地落库都有。1.2 三类数据在整个量化流程里的定位先明确一个概念这三类数据不是同一类用途。分钟数据是历史数据主要用来回测和策略因子计算买卖五档是实时数据主要用来做盘口监控、主力异动识别、下单执行辅助竞价数据是极短窗口的快照数据主要用来做开盘情绪判断和日内方向预判。我自己做A股日内策略的流程是这样的昨晚复盘选股池今天9:15开始拉竞价数据9:25确认开盘价和匹配量9:30开盘后切到五档数据观察盘口变化盘后用分钟数据做当天的策略回测和参数修正。这个过程里三类数据缺一不可少了任何一环策略都像缺了一条腿走路。2. 数据源选型免费接口和付费接口怎么取舍这一节我直接说结论我目前用的是“免费源做备份 廉价付费源做主数据”的组合。很多人一上来就想找全免费的数据源我能理解但做过一段时间之后你会发现免费数据源节省的是钱消耗的是时间而且消耗的时间往往比省下来的钱更贵。数据源选型不能只看“能不能拿到数据”还要看“数据全不全”、“稳不稳定”、“字段是否是原始值”、“有没有技术支持”。这几点在真正做策略的时候比接口是否免费重要得多。2.1 免费源的风险清单免费源最大的问题不是速度而是“文档和实际返回不一致”。我遇到过两次印象特别深的情况。第一次文档里写的返回字段是last_price实际返回的是price字段名不同改一下映射表就能解决但如果你的代码里写死了字段名就得动一堆逻辑。第二次更坑免费接口的请求频率限制会悄悄变化今天允许每3秒一次下周变成每10秒一次你的日志里开始大量出现429状态码不仔细排查根本发现不了。还有一个容易忽视的问题免费接口偶尔会停服维护而且没有任何提前公告。维护期间正好是开盘时间你的策略就只能干看着。所以免费源不是不能用而是不能把它当生产环境的唯一依赖。2.2 付费源的隐藏成本付费源也不是一劳永逸。按量计费适合前期测试但分钟数据拉多了每次请求都在烧钱。包月订阅看起来更可控但要注意套餐里包含的究竟是“真正的五档”还是“五档快照”以及“tick级数据”到底是逐笔成交还是500毫秒切一次片的快照数据。这两个概念差的不是一点半点拿到手之后处理逻辑完全不同。另一个容易被忽略的成本是权限拆分。很多平台把K线、五档、竞价数据分开售卖单独看每个都不贵加在一起就肉疼了。我自己选型时有一个原则先把真正需要的数据列出来再留一点冗余预算最后算总价而不是看到哪个套餐便宜就买哪个。2.3 高性价比的组合方案我目前的组合是这样历史分钟K线用某个基础套餐免费额度相对充足日常增量拉取够用五档数据用另一个平台的WebSocket推送只订阅持仓股和自选股不订阅全市场竞价数据用HTTP快照在9:15到9:25这段时间高频轮询开盘后立刻停止。这样拆的原因是不同数据源在各自擅长的场景下延迟和成功率确实有差异。把五档拆到WebSocket推送源能减少HTTP轮询一半以上的请求量也避免了快照接口因为频繁请求被封禁的风险。数据源不是越贵越好也不是全都要用一个平台按场景拆分使用往往性价比最高。3. 分钟数据接口复权、频率、批量拉的底层逻辑分钟数据是三类数据里最“看着简单、做起来复杂”的一类。接口返回一串JSON数组看起来就是时间、开高低收、成交量但真正对接过就知道复权、时区、交易时段、增量更新这些问题一个比一个麻烦。3.1 复权因子会让你的K线对不上账很多人在拉分钟数据时默认参数是“不复权”或者“前复权”。做回测的时候一旦股票除权除息除权那天的一根K线会突然跳空如果策略里用了均线、布林带这种依赖价格连续性的指标跳空会被误判成突破或者异常回测结果直接失真。这里有一个容易忽视的细节分钟线本身没有独立的复权因子它是按日线复权因子换算出来的。如果数据平台没有提供日线除权因子分钟线的前复权就可能不准。所以我的经验是做回测时统一用“后复权”数据因为后复权从上市首日开始连续复权数据序列最稳定盘中监控看实时价格时再用“不复权”原始价因为交易下单需要的是真实价格。两种场景分开处理能避免很多策略层面的干扰。3.2 接口设计的频率参数与映射常见分钟频率有1分钟、5分钟、15分钟、30分钟、60分钟部分平台还支持3分钟、45分钟等非常规频率但不是所有都支持。我调接口前一定会先看文档里的频率枚举值不同平台字段名差异很大有的用1m有的用1min有的直接传数字1。以Python的requests为例拉最近几根1分钟K线的代码可以这样写import requests import time BASE_URL https://your-data-source/api/v1/line def get_min_kline(symbol: str, freq: str 1m, count: int 10): params { symbol: symbol, freq: freq, count: count, ak: your_api_key, ts: int(time.time() * 1000) } resp requests.get(BASE_URL, paramsparams, timeout5) data resp.json() if data.get(code) ! 0: raise RuntimeError(data.get(msg, unknown error)) return data[data][list]返回的list通常包含time、open、high、low、close、volume、amount这几个字段。有一个细节必须提醒很多平台返回的open、close是字符串类型比如7.32不转换成float型后续算指标时会报错或者得出错误结果。我在代码里会统一加一层类型转换。3.3 分钟数据怎么接进本地库数据量上来之后每次全量拉取不仅慢还容易触发限频。我的做法是“首次全量 定时增量”。建一张kline表主键是(symbol, freq, time)首次同步时拉最近N根K线写入增量更新时每隔3到5分钟拉最近2根按时间戳比对后写入。增量拉取有一个关键技巧把起始时间往前多拉1根。因为接口落数据经常有延迟当前这根1分钟K线要等这分钟彻底结束后才完整可用如果恰好在这个窗口期拉数据拉到的最后一根K线数据可能是不完整的。多拉1根再靠主键去重能有效避免漏数据这个习惯帮我少踩了很多坑。4. 买卖五档数据HTTP快照和WebSocket推送的取舍买卖五档是短线玩家最关心的数据之一。想做实时盘口监控、主力资金异动识别没有五档数据基本无从下手。但五档数据的获取方式和分钟数据完全不同它的实时性要求更高接口对接方式也更复杂。4.1 五档和十档不是数字差两个那么简单A股常见的level1行情是五档level2是十档但两者的差距不只是档位数。五档只能看到买卖双方各挂五档的价格和量十档能看到更深的挂单分布更重要的是Level2还有逐笔成交明细可以还原每一笔单子的成交路径这对识别大单拆分、主力进出有质的区别。但Level2数据源通常按年费和License授权收费个人开发者要拿到正经的Level2授权门槛和成本都不低。所以我的建议很现实如果只是个人研究五档快照够用如果做高频或实盘辅助再去考虑Level2。不要一开始就all in贵的。4.2 HTTP快照轮询低成本的准实时方案HTTP快照的方式是每次请求都返回当前时刻完整的五档数据。它的优点是实现简单、部署成本低、不容易因为连接断开丢数据缺点是只能做到准实时每次请求之间有一个轮询间隔如果轮询太频繁又会触发限频。一个简单的五档快照拉取代码如下def get_orderbook(symbol: str): params {symbol: symbol, ak: your_api_key} resp requests.get(https://your-data-source/api/v1/depth, paramsparams, timeout5) data resp.json() if data.get(code) ! 0: raise RuntimeError(data.get(msg, unknown error)) return data[data]返回体大概长这样{ symbol: 600000, ts: 1693000000000, bids: [ {price: 7.32, volume: 1200}, {price: 7.31, volume: 800} ], asks: [ {price: 7.33, volume: 900}, {price: 7.34, volume: 1500} ] }轮询频率我建议3秒一次比较安全具体取决于数据源限频规则。如果只是监控盘口变化不需要每次都全量处理算两帧之间的差量就够了能大幅减少计算开销。4.3 增量推送真正的实时盘口要这么写如果做的是实时监控或者高频交易辅助HTTP轮询的延迟不能满足需求这时候需要走WebSocket。订阅一个symbol后服务端会持续推送增量消息格式一般类似{symbol:600000,type:snapshot,data:{...}} {symbol:600000,type:update,data:{side:bid,pos:2,price:7.32,volume:800}}增量推送不能直接覆盖本地盘口要做合并。规则是收到snapshot就把整块数据覆盖到本地盘口收到update则只更新对应档位。这个“本地维护盘口”的过程看着简单但很容易踩坑。比如有些推送源的档位序号从1开始而不是从0开始如果没对齐你更新的就是错误的档位。另一个更隐蔽的问题是WebSocket连接一旦断开重连后如果只等增量推送中间丢失的增量消息会导致本地盘口失真。我的方案是维护一个本地时间戳重连成功后先拉一次snapshot校准再开始接收增量。这样既保证了实时性又避免了数据不一致。5. 竞价数据开盘前最容易忽略的“黄金窗口”竞价数据是A股特有的一个数据场景很多刚接触接口开发的朋友一开始根本不会想到去取它。但做过短线的人都知道9:15到9:25这10分钟里蕴含的信息量可能比开盘后半小时的数据更值得关注。5.1 集合竞价的时间规则与数据特点A股集合竞价分两个阶段9:15到9:25是开盘集合竞价14:57到15:00是收盘集合竞价。其中9:20之前可以撤单9:20之后不能撤单。对数据接口来说9:15到9:20之间的虚拟匹配价会一直跳动因为可以撤单盘口会出现很多“虚假挂单”9:20到9:25之间挂单锁定价格开始收敛最终在9:25撮合出开盘价。所以抓竞价数据通常要在9:15到9:25之间以较高频率轮询比如每1秒拉一次快照把当前的虚拟匹配价、匹配量、买卖双方未匹配量都记录下来。9:25之后竞价结束这些数据基本定格再拉也拉不到更多信息了。5.2 竞价数据里能挖出什么指标我自己常用的竞价指标有三个竞价匹配量反映参与集合竞价的资金规模。量特别大说明当天该股票的关注度极高可能是利好刺激也可能是多空分歧剧烈。竞价涨幅9:25竞价价格相对昨日收盘价的涨跌幅。偏离过大说明情绪极端追高风险上升。未匹配买单和卖单量如果卖单未匹配量特别大意味着开盘后可能有一波抛压反之买单未匹配量大则可能开盘拉升。这些指标单独看没有绝对意义需要结合个股的历史数据和当日板块环境综合判断。比如昨晚选好的一批股票今天竞价涨幅超过5%且匹配量异常放大我一般会直接放弃追高。5.3 竞价数据抓取与落库实践竞价数据我是以“每个交易日一个表”的方式存储的字段包括symbol、time、price、volume、bid_vol、ask_vol。这里的price是当前虚拟匹配价volume是当前匹配量bid_vol是未匹配买单量ask_vol是未匹配卖单量。代码片段类似def fetch_auction(symbol: str): params {symbol: symbol, ak: your_api_key, type: auction} resp requests.get(https://your-data-source/api/v1/snapshot, paramsparams, timeout5) data resp.json() return data[data]轮询频率我建议1秒1次9:15到9:25一共600秒理想情况下一个股票会有600个时间点记录。但要注意竞价的这段时间恰好是数据源整体的峰值高并发窗口限频风险远高于其他时段。我的经验是提前做一次压测确认数据源在这个频率下能稳定返回如果不行就降低到2秒一次优先保证数据可用性。6. 高频调用下绕不过去的坑限频、字段、时间戳前面讲了三类数据各自的对接方式这一节专门讲坑。因为即使接口文档写得再详细实际对接中总会遇到一些文档里没写、但一旦遇到就能卡你半天的问题。6.1 限频被卡之后怎么办被限频最典型的特征就是HTTP 429或者返回code403。看到这个状态码别慌先做两件事第一看服务端返回的Retry-After头它告诉你要等多久才能继续请求第二翻自己日志里的请求频率看是哪个任务集中爆发导致了限频。我踩过最大的坑是本地5个脚本同时运行每个脚本单独看请求频率都在合法范围内但合起来的总请求量翻了几倍直接被限频。解决方法是把所有的请求集中到一个统一调度模块由它统一管理请求频率和鉴权而不是每个脚本各发各的。这样既能精准控制频率也方便排查问题。6.2 字段类型和精度坑不同平台返回的数字字段可能是number、string甚至是带单位的字符串。我遇到过把成交量返回成123.4万的情况看起来是人读友好程序处理起来却很要命。所以对接任何接口第一步一定是先抽样打印原始返回确认字段类型后再写解析逻辑。价格精度也要注意。A股价格最小变动单位是0.01元但有些平台返回的是保留4位小数的字符串比如7.3200用float解析没问题但如果直接拿去做SQL的where条件可能因为浮点表示误差匹配不上。我一般用decimal或者按“分”为单位存整数彻底规避浮点精度问题。6.3 时间戳与时区问题分钟数据和五档数据返回的时间戳大部分是Unix毫秒但也有些平台返回秒级时间戳甚至直接返回字符串2026-01-01 09:30:00。统一处理方法是我定义了一个时间解析入口所有时间戳都经过它转换成本地时区后再以%Y-%m-%d %H:%M:%S格式存库。还有一个容易踩的坑是日切问题。股票数据的时间范围是交易时段内但很多平台在夜间会返回昨天的最后一帧快照。如果不判断“当前时间是否在交易时段内”你拉到的就是昨天的旧数据。我一般会在拉快照后加一个简单的时间窗口判断非交易时段直接跳过既能省配额也能避免脏数据。7. 关于这个接口合集我的下一步打算到这里分钟数据、五档数据、竞价数据的对接已经基本串起来了。下一步我计划把这几类数据统一封装成一个Python包对外提供get_kline、get_depth、get_auction三个方法内部做配额统一控制和自动重连。这样不管底层数据源怎么换上层的策略代码都不用改。另外这套东西后续还可以往两个方向扩展一是把盘中实时数据接入可视化看板做一个自用的盘口监控页面二是把竞价数据和分钟数据联合起来生成一份每日开盘前的“市场情绪快照”辅助决定当天的整体仓位。根据我这几个月来回对接数据源的经验最深的感受是做数据接口对接最怕的不是接口本身复杂而是文档和实际返回不一致。文档写得天花乱坠实际返回里字段名错一个、类型变一下就能让你排查一整天。所以每次对接新接口我都在动手写代码之前先花10分钟把原始返回完整打印出来对着文档逐字段核对。这10分钟看着是浪费实际上能省下后面一整天的排错时间。