做量化回测、写行情监控脚本、搭个人数据看板最让人头疼的往往不是策略本身而是数据。自己去爬网页反爬机制分分钟教你做人买付费终端一年几千块的费用个人开发者很难扛住。这几年我前前后后把股票、期货、外汇、数字货币四个市场的免费API都接过一遍踩了不少坑也整理出一套相对顺手的接入方法。这篇文章不搞“十大免费接口盘点”那种标题党列个表就完事没有意义。我打算从实际接入的视角把每个市场的鉴权方式、数据格式、字段陷阱、维护技巧一次说清楚让你既能跑通也不容易在后续维护中翻车。1. 免费金融数据接口怎么选先看清三类来源和适用场景1.1 免费接口从哪来官方直供、聚合平台、开源包装先梳理一下市场上免费数据的来源很多刚入门的朋友一上来就搜“免费API”然后被各种平台的宣传晃花了眼。实际上免费金融数据无非三类来源。第一类是官方直供。有些交易所会直接提供公开行情接口比如部分商品交易所的日行情数据下载或某些海外交易所的公开行情API。这类接口最大的优点是权威、字段相对标准但缺点是覆盖面窄如果既要拿股票又要拿期货数据往往要对接好几家各家文档风格还不一样维护成本直线上升。第二类是第三方聚合平台。这类平台会把多个市场的行情统一包装成API免费版通常有调用次数和频率限制但胜在数据类型多、格式趋近一致。我的经验是个人开发者和量化入门者做数据源首选就是这类平台因为省掉大量字段对齐工作。不过免费档的限制要提前摸清楚有的平台限制历史数据只能拉最近两年有的只给日线不给分钟线注册前先看文档。第三类是开源社区的包装库和爬虫。社区里有很多现成的开源库底层可能用爬虫抓取行情页面。这类方案的优势是免费、灵活、接口形式往往很友好缺点是反爬升级时容易失效数据延时也看运气碰上页面改版就只能等社区更新。我建议用它做备用数据源不要当主源。一旦主源挂了备用源能让你不至于完全停摆。这三类来源没有绝对的好坏关键是匹配你的使用场景。我的选型标准很简单回测和策略研究优先用聚合平台实时行情监控找支持WebSocket的官方直供开源库只做应急备用。下面这张表可以帮你快速判断该往哪个方向找来源类型优点缺点适合场景官方直供权威、字段标准、数据可靠覆盖面窄、多市场要对接多家单市场实时行情、深度数据第三方聚合多市场统一、格式相近、接入快免费限制多、频率低、可能缺历史个人研究、回测、多市场看板开源包装免费灵活、社区活跃稳定性差、有反爬风险、需自行维护应急备用、低频数据采集1.2 选型之前先想清楚这四件事具体选哪家接口之前别急着注册账号先把四个问题想明白这可以省掉很多后面改代码的麻烦。第一个问题是数据频率够不够。免费接口一般只到分钟级tick级逐笔数据基本都要收费。对回测来说日线已经能解决大部分问题做日内策略才需要分钟线如果只是搭一个每日收盘后的数据看板日线绰绰有余。先确认自己的分析粒度再去挑数据源避免花大力气接了高频接口却发现用不上。第二个问题是协议方式适不适合。HTTP轮询简单直接适合低频任务WebSocket适合实时高频场景。我自己做实时监控时数据源优先选支持WebSocket的因为分钟级K线如果用轮询每秒都要请求一次很容易触发限流。反过来如果你只是每天跑一次定时任务拉数据完全没必要上WebSocket徒增连接管理的复杂度。第三个问题是数据质量能不能接受。免费数据常见的坑有历史数据不全、字段缺失、复权处理粗糙。你要判断的是这个数据源能不能满足你的准确性要求。做战略研发数据里多几个空值可能就会导致结果偏差这块不能马虎。第四个问题是合规和使用限制。免费接口通常都有服务条款比如不能商用、不能大量缓存。做个人研究和学习没有问题打算商业落地前一定要确认使用限制。数据源被封号是小事因此带来合规风险才是大麻烦。2. 股票与期货接入实操字段、复权、合约规则一次说透2.1 股票行情接口的鉴权与核心字段处理股票数据是需求量最大的也是新手最容易踩坑的。先说鉴权免费接口一般通过token完成认证。注册账号之后在个人中心生成一个token然后请求时放到请求头里import requests api_url https://api.example.com/stock/daily params { symbol: 000001, start: 20240101, end: 20241231, adjust: qfq } headers {Authorization: Bearer 你的token} resp requests.get(api_url, paramsparams, headersheaders, timeout10) if resp.status_code 200: data resp.json()[data] else: print(请求失败, resp.status_code)这里有几个细节值得多说几句。为什么请求要带timeout免费接口稳定性参差不齐不带超时的话一旦服务端挂起你的脚本会一直卡住影响整个任务链路。我习惯设10秒超时就记录日志并重试。重试次数和退避策略也要有连续三次失败就切换备用数据源而不是无限重试。为什么复权参数要单独设置股票分红送股之后历史价格会出现断层。不复权adjustnone数据会让K线出现假跳空比如一只股价从10元突然变成8元看起来像暴跌实际上只是除权除息。前复权qfq用当前价格水平回推历史后复权hfq用历史价格水平递推到现在。回测分析我一般用前复权计算收益率更接近真实情况做技术指标研究则要看具体场景如果指标依赖绝对价格不复权更合适。这些概念听起来抽象但实际跑一遍数据对比就一目了然。拿到行情数据后典型的字段包括时间戳、开盘价、最高价、最低价、收盘价、成交量。不同接口的字段名不一样有的叫open有的叫open_price有的时间返回字符串有的返回时间戳。所以我强烈建议在接入层做一次统一的字段映射把所有数据源都转成同一套结构STANDARD_COLUMNS { open: open, high: high, low: low, close: close, volume: volume }这样下游不管接哪个数据源策略代码都不用改。这一层抽象看起来简单但在多数据源并存时能省下大量调试时间。我甚至会把原始返回的JSON完整保存一份到一个日志目录出问题时不至于只能对着局部数据结构猜。股票接入还有一个很容易被忽略的点交易日历。免费接口多数不会提醒你哪天休市。如果直接按自然日去取数、按行数计算均线一到长假就会算出错误结果。解决办法是维护一份交易日历表或者按接口返回的日期过滤非交易日。交易日历在网上能找到现成的数据文件也可以自己用历史数据推断但要注意节假日调整安排比如调休导致的周末开市。2.2 期货数据里最容易被忽略的连续合约问题期货比起股票多了一个“合约”维度这是新手最常栽跟头的地方。每个期货品种在不同月份都有对应合约比如螺纹钢的主力合约是成交量最大的那个月份。直接拿一个月份的合约拉历史数据会遇到两个问题一是单个合约的活跃期可能只有几个月历史深度不够二是主力合约会换月如果简单把前后两段拼接价格会因换月产生跳空技术指标会算错。免费接口对期货数据通常有两种提供方式一种是按具体合约月份取数一种是直接提供“主力连续合约”。我建议优先用主力连续因为它按成交量动态切换主力历史连贯性最好适合做策略回测。代码示例import requests url https://api.example.com/future/daily params { symbol: rb8888, # 某商品期货主力连续合约示意代码 start: 20240101, end: 20241231 } resp requests.get(url, paramsparams, timeout10) data resp.json()[data]拿到数据后最好再核对一下持仓量或成交量字段确认这段数据在换月点是否被接口做了特殊处理。有些接口会标注“换月标记”有条件的话可以基于这个标记来自动剔除换月当日的异常K线。换月当天的K线往往同时包含旧合约的尾盘和新合约的开盘成交量会出现明显放大或萎缩直接用会影响指标计算。夜盘也需要单独处理。商品期货有夜盘时段部分品种交易到次日凌晨。如果你拿的是按日期切分的数据注意接口默认的时间切分是以几点为界。我遇到过把夜盘算进前一天的数据源也遇到过把夜盘和次日日盘算成同一天的数据源两种结果对日内指标计算影响很大。处理方法是统一按交易所官方时间规则切分自己写一个时段映射表不要依赖接口的默认行为。比如螺纹钢夜盘是21点到23点那23点之后的数据应该归到下一个交易日而不是当天。3. 外汇与数字货币的实时API两个容易踩坑的市场3.1 外汇数据报价源、时区与休市外汇免费数据比股票期货都要“虚”一些。先解释一下外汇市场没有统一的交易所报价来自全球各大银行和做市商。不同数据源拿到的同一货币对价格可能在最后几位小数上有差异这很正常。免费接口的报价通常来自某一家或几家聚合报价源你只能接受这个报价没有太多选择空间。接入外汇数据时第一个要解决的是时区问题。外汇市场24小时交易但结算时间点不是自然日零点而是美东时间下午5点这造成了“一个交易日横跨两个自然日”的情况。如果你用自然日划分数据日线会错位。我建议设定一个明确的交易时段定义比如“每天凌晨5点到次日凌晨5点为一个交易日”并在代码里统一处理import pandas as pd df[datetime] pd.to_datetime(df[datetime], utcTrue) # 统一转成自定义交易时段的标签 df[trade_date] df[datetime].dt.tz_convert(America/New_York).dt.date第二个问题是“实时”二字要打折扣。很多免费外汇API宣称实时报价实际上数据源本身可能是15分钟或20分钟快照。我测试过几个平台网页端看着是跳动的实时价格接口返回的却是缓存数据。做回测问题不大但如果你要基于报价做实时交易信号一定要先做延迟测试。测试方法很简单连续调用接口取同一个货币对的最新价同时记录本地时间然后和网页端报价对比多测几次就能看出延迟范围。第三个问题是休市。虽然外汇是24小时交易但周末会休市重要节假日流动性极低。免费接口在休市时段返回的数据可能是最后一条报价的重复值也可能是空值这会让你的K线图上出现一段“死线”。处理方法是根据货币对所属市场维护一个开闭市日历休市时段直接跳过去不做补数避免产生虚假交易记录干扰分析。3.2 数字货币数据REST与WebSocket双通道怎么用数字货币市场是免费API最丰富的领域几乎每家交易所都提供公开行情接口。但丰富也意味着碎片化同一时刻的BTC价格在不同交易所可以差出几十甚至上百美元K线的字段命名和返回结构也各不相同。数字货币的行情数据主要有三类K线、深度、成交明细。K线适合做技术分析和回测深度和成交明细适合做实时监控。免费接口里REST适合低频拉K线和历史数据WebSocket适合实时订阅。REST拉K线的典型写法import requests url https://api.example.com/market/kline params { symbol: BTC/USDT, interval: 15m, limit: 200 } resp requests.get(url, paramsparams, timeout10) data resp.json()WebSocket订阅就麻烦一点。交易所的WebSocket一般要求先发订阅消息再收推送数据。我实际用下来最大的坑有两个断线不重连、心跳不处理。很多免费接口的WebSocket服务端会定期断开闲置连接客户端如果不实现心跳和自动重连过一会儿数据就停了而你的程序看起来还在跑。我自己踩过一次监控脚本运行两小时后静默掉线数据全丢了日志里没有任何报错。订阅和重连的框架大概是这样import json import websocket def on_message(ws, message): msg json.loads(message) # 处理行情数据 if msg.get(type) ticker: print(msg[data]) ws websocket.WebSocketApp( wss://api.example.com/ws/market, on_messageon_message, on_errorlambda ws, err: print(错误:, err) ) # 启动后先订阅 def on_open(ws): ws.send(json.dumps({ type: subscribe, channel: kline, symbol: BTC/USDT, interval: 1m })) ws.on_open on_open ws.run_forever(ping_interval30, ping_timeout10)ping_interval和ping_timeout这两个参数就是心跳机制。我在测试中发现设置30秒一次的心跳可以大大降低被服务端主动断开的概率。即使断开了也要在on_close回调里做自动重连逻辑而不是让程序默默退出。重连之后要重新发订阅消息否则看起来连上了实际上收不到数据。数字货币数据还有字段对齐的问题。不同交易所的K线返回时间戳有的用秒、有的用毫秒有的返回数组有的返回对象。我统一在接入层做一层转换时间戳统一转成毫秒整数价格字段按开高低收统一命名。另外不同交易所之间的价差有时会成为策略的一部分如果你做跨交易所监控记得给每个数据源加上source字段标识。这里多说一句合规数字货币交易在不同地区的监管政策差异较大本文只讨论数据接口的技术接入方式不构成任何投资建议。实际使用相关数据时先确认所在地区的合规要求不要想当然。4. 跑通一条完整接入链路从token申请到数据入库4.1 统一数据模型和缓存策略前面我反复提到“统一数据模型”这里单独展开讲一下因为这是整条接入链路的骨架。我设计的标准数据结构包含五个核心字段timestamp、open、high、low、close、volume。外加一组扩展字段symbol、source、interval。所有市场的数据在进入本地存储之前都先转成这个结构。这样做的收益我在同时维护四类数据源之后体会特别深。如果每个数据源各自为政下游做策略回测时就要写四套读取代码。统一模型之后四类市场的数据可以并存于同一张表里按symbol和interval区分策略代码写一次就够了。source字段很多人会忽略。当你同时接了两家股票数据源做交叉验证时没有这个字段出了问题都不知道是哪家的数据。我习惯每个数据表都带source字段后续排查问题时能少走很多弯路。缓存策略也值得说一下。免费接口往往有频率限制但历史数据又是低频更新的完全没必要每次跑脚本都重新拉一遍。我的做法是历史数据第一次全量拉取后存本地之后每天只增量拉最近几天的数据启动脚本时先读缓存再拉增量缺口。这样既省调用额度又减少等待时间。4.2 增量更新的断点续传思路增量更新的核心是断点续传。简单说就是记录“上次拉到哪里了”下次从这个位置继续拉。我用最朴素的方式实现在存储表里维护一个last_update字段每次更新时查一下每个标的的最新数据时间然后只请求这个时间之后的数据。代码逻辑def fetch_incremental(symbol, interval, last_ts): params { symbol: symbol, interval: interval, start: last_ts, limit: 500 } # 发起请求并解析 new_rows fetch_and_parse(params) return new_rows注意两个细节一是免费接口的单次请求通常有限制比如一次最多返回500根K线超过要分页拉取二是分页时注意最后一页和下一页之间的重叠否则会丢数据或重复插入。我习惯在写完数据后做一次去重用timestamp加symbol作为唯一约束重复数据直接跳过。本地存储的选型我最常用的是SQLite。免费数据量对个人研究来说完全够用SQLite单文件、零运维一条命令就能建库。数据量特别大或需要并发读写时再考虑其他数据库。历史K线导出为Parquet归档也不错分析和读取都很快尤其是当你的数据量积累到几百万行之后CSV的读取速度会明显拖后腿。4.3 四类市场的接入代码细节股票、期货、外汇、数字货币的REST接入代码框架大同小异区别主要在参数和返回结构上。我把四个市场的请求参数各自列一下你照着改就行。股票注意复权参数params {symbol: 600000, period: daily, adjust: qfq}期货注意合约代码params {symbol: au8888, period: daily} # 贵金属主力连续示意外汇注意货币对代码和报价模式params {pair: EUR/USD, mode: latest}数字货币注意交易对和K线周期params {symbol: BTC/USDT, interval: 1h, limit: 500}返回结果的解析上各家用JSON的居多但嵌套层级不一样。我建议先打印一次原始返回值看清楚结构再写解析代码不要靠猜。打印原始数据这个动作看起来简单实际上能省掉大量试错时间。我见过不少朋友对着接口文档猜字段层级猜了三层还写不对打印一下一目了然。另外务必把请求频率控制好。大部分免费接口的限制在每分钟几十次到几百次不等。我的经验是按需拉数时每次调用之间至少间隔0.2秒循环拉大量标的时加一个随机小延时避免出现节奏性触发限流。限流之后往往要等一分钟甚至更久反而拖慢整体进度。5. 免费接口高频故障与排查实录5.1 高频踩坑速查表免费接口用久了总会遇到各种问题。下面这张表是我整理的高频故障速查出现症状可以直接对照症状可能原因排查方法请求返回429调用频率超限加请求间隔、减少并发、换备用token请求超时接口不稳定或网络问题设置合理timeout并重试连续失败则切备用源数据中间缺一段停牌、除权除息、临时休市核对交易日历做复权处理历史数据拉不全接口分页限制按时间段分批拉取合并后去重时间错乱时区或交易时段划分不一致统一转UTC时间戳存储展示时再转本地时区WebSocket静默掉线心跳未处理或连接被断开实现ping心跳和自动重连字段名对不上接口版本升级或不同数据源差异接入层维护字段映射表升级时改映射即可排查的时候我习惯遵循“先本地后远端”的顺序先确认本地代码没有改坏、没有限流、没有存错数据再怀疑接口返回异常。很多时候问题出在本地增量逻辑上尤其是断点续传写得不严谨会导致缺数。比如分页拉数据时每页的参数没有正确接上就会漏掉中间一段表现就是数据在某个时间段突然缺失。5.2 我实际踩过的三个数据坑第一个坑是股票除权造成了回测收益虚高。有次我拿某只股票做回测用不复权数据发现某一天收益率突然出现一个巨大的跳变。一开始以为是策略信号仔细查了才发现那一天是除权日股价直接下跳而我的策略代码按正常涨跌来计算结果出现了明显异常的“收益”。后来统一改成前复权数据回测结果才回归正常。这个坑让我明白免费数据源的“原始数据”不等于“可用数据”复权、停牌、除权标记这些处理做分析前必须过一遍。第二个坑是期货夜盘的K线拼接错乱。我一开始拿到的数据是按“自然日”切的夜盘归前一天日盘归当天。我写指标时直接按行号滚动计算日均结果每天的开盘数据里混着前一天的夜盘尾盘均线轨迹完全变形。后来我按交易所的交易时间段做重新切分把夜盘和次日日盘拼成完整交易日问题才解决。做期货的朋友接入后第一件事就是确认接口的时间切分规则不要假设它和你的预期一致。第三个坑是外汇“实时报价”的延迟。有次我基于某个外汇免费API写了一个实时汇率看板上线后发现价格和主流行情软件对不上。刚开始以为是数据源价差后来做了延迟测试发现API返回的价格实际是15分钟前的快照。看板做展示没问题但拿它做短线信号就完全不靠谱。这次之后我对外汇免费API都会先做延迟体检周期行情用日线没问题实时性要求高的场景则要用官方直连报价源。给一个延迟体检的具体做法每隔几秒轮询一次最新价记录下来后和行情软件对照连续测10分钟就能看出数据延迟的大致区间。这个方法同样适用于数字货币和其他“宣称实时”的接口。测出来的延迟结果记到自己的数据源评估表里后面选型时会非常有用。最后几点经验把四个市场的免费API都接完之后我最大的感受是免费接口不是“拿来就能用一辈子”的东西它是有生命周期的。接口地址会变、字段会升级、频率限制会收紧你可能今天跑得好好的代码明天一觉醒来就报错了。所以我一直建议数据接入层一定要和业务代码解耦。把“从哪里取数”和“怎么用数”分开数据源升级了只改接入层策略代码不用跟着动。统一的字段映射、标准的存储格式、断点续传的增量更新这三件事做好即使某天换数据源迁移成本也很低。另外任何免费数据源都要准备一个备用方案。我自己的习惯是主源加备源双跑一段时间确认主源稳定后再切掉备源。文件存储、代码注释、接口文档里的重要字段说明都养成随手记录的习惯这些习惯比接口本身值钱。既然你已经看到这里说明大概率准备动手接数据了。我的建议是别一上来就铺四个市场先选一个你最熟悉的市场跑通最小闭环拿到token、拉一次数据、存进本地、画出一张K线图。这一步完成后再扩展到其他市场会轻松很多。数据链路稳定了后面无论是做回测、写监控还是搭看板都是水到渠成的事。