如果你在搜索引擎里敲下港股实时api这几个字大概率会发现一个很有意思的现象搜索结果里全是看着像那么回事的接口文档和教程点进去却要么失效、要么延迟严重、要么塞满了各种隐藏条件。我过去大半年一直在给自己的监控脚本接港股实时行情前前后后试了七八种渠道踩了不少坑最后才把一套相对稳定、成本又可控的方案跑起来。这篇就把我从到处找不到到终于找到了的完整过程写出来包括不同渠道的真实差别、接入时的关键参数、以及文档里根本不会写的那些坑。文章尽量按时间顺序来先说为什么这个接口难找再讲我实测过的几类渠道然后给出一套可以直接照着做的接入流程最后聊几个接入之后才会遇到的问题。无论你是做个人盯盘工具、量化研究还是行情展示应该都能从里面找到有用的部分。1. 为什么一搜港股实时api得到的结果大多跑不通1.1 港股行情从交易所到你屏幕的完整链路很多人在最开始就搞错了一件事以为行情数据和股票代码一样是公开免费的资源。实际上港股的实时行情是一条完整的商业链路每一层都在收钱。源头是香港交易所它产生所有成交数据但并不直接面向普通开发者开放。港交所会把这些数据授权给两类机构一类是持牌资讯供应商像路孚特Refinitiv、彭博它们另一类是交易所参与者也就是券商。券商拿到授权之后再提供给自己的客户这个过程中还会叠加一层费用。换句话说你能看到的每一个实时报价背后都经过了至少两到三次转授权。这就解释了为什么内地行情软件里A股默认能看到实时报价而港股默认只给你延迟15分钟的数据。A股行情是交易所免费分发分发成本由交易所承担了港股不一样授权费是按终端数量、按订阅人数来算的。哪怕是个人的小工具只要用到实时行情理论上都涉及授权费用的问题。所以当你搜港股实时api搜到的那些永久免费完全实时的接口基本可以断定有问题。要么是延迟行情伪装成实时要么是别人的试用接口拿出来分享要么就是随时会被封的抓包接口。1.2 免费实时为什么在港股行不通我不是说完全不存在免费的实时通道而是说免费的通道都有非常明确的限制达不到拿来做生产环境的标准。我早期试过几个号称免费的接口接入第一天数据是实时的第二天请求量稍微上来一点IP直接被封第三方接口的稳定性就是这么脆弱。还有一类是试用型接口有些量化平台会提供港股的实时接口试用权限给几百万次请求或者几天有效期的体验额度。用于验证功能完全没问题但试用期一过你就得面临两个选择付费或者再找下一个试用源。如果你只是想跑个Demo那这类很合适想长期挂在服务器上这条路走不通。真正合规且长期可用的实时港股行情只有两条路一是你有一个支持港股交易的券商账户通过券商自己的API获取二是向有行情授权的服务商付费订阅。前者适合已经有交易账户的人后者适合机构或者预算充足的人。这个认知是我试错了几周之后才彻底接受的。1.3 先分清你需要的是快照还是连续推送还有一个很容易被忽略的问题你需要的是快照Snapshot还是连续推送Streaming快照就是某个时刻的静态行情比如现在腾讯的价格是多少通过HTTP请求就能拿到。连续推送则是通过WebSocket这类长连接服务端主动把每一笔行情变化推给你。个人做盯盘工具、异动监控基本需要的是连续推送因为快照请求本质上是轮询你很难判断下一秒价格会不会变轮询太频繁还会遇上限流。另外实时行情本身也分等级。交易软件里常见的Level 1五档行情和Level 2逐笔成交是不同的数据产品。Level 1够做绝大多数个人应用Level 2价格通常翻好几倍。我在选型的时候一开始想的全是我要最实时的数据后来想明白了我的策略最多用到分钟级别Level 1绰绰有余。2. 我实际跑过的几类港股API渠道、延迟与费用2.1 券商自带API以盈透证券为例先说我试的第一条路券商API。盈透证券IBKR支持港股交易也有开放API接口很多全球交易的程序员都用它。优势很明显行情数据合法合规数据源直接来自它自己的行情Feed稳定性有保障文档也算齐全。不好受的是接入方式。IBKR的API要求你本地跑一个网关IB Gateway所有请求都要先跟这个网关建立连接而且连接时需要用固定的Client ID。如果你之前没接触过它的TWS API光是理解API是跑在本地进程里的代码只是给这个进程发指令这个模型就要花掉一些时间。另外它的行情免费额度是有限制的超过免费额度还会被扣积分。我的结论是这条路径更适合本来就做全球交易、想顺带把行情拉出来的人。只为了港股行情去新开一个账户、熟悉一套协议性价比不高。2.2 互联网券商开放平台很多个人开发者的终极选择第二条路也是我最终采用的方案是互联网券商提供的开放API典型代表是富途的OpenAPI。富途本身是做港美股交易的后来开放了行情和交易接口提供Python SDK和本地终端支持港股、美股、A股的实时行情订阅。接入体验比IBKR友好太多。SDK封装好了连接、鉴权、订阅这些逻辑你只需要写业务代码。申请流程大概是开一个富途账户 - 完成入金门槛 - 在开放平台申请API权限 - 下载OpenD本地网关进程- 用SDK连接。这里有一个很多人不知道的关键点API连接成功之后能不能收到实时行情取决于你的账户有没有单独开通对应交易所的实时行情权限。富途的港股LV1行情在某些时候是免费送的LV2才需要付费具体以你开户时的活动为准。如果没开通SDK连上了也只能拿到延迟数据。实测下来从订阅到收到推送的延迟大概在几百毫秒到1秒这个区间对于个人监控和低频策略完全够用。稳定跑了几个月断线重连机制做对之后基本没再需要人工干预。2.3 机构级数据服务商贵且复杂个人一般不用碰我也咨询过几家里面的传统数据商比如路孚特、彭博这类。它们的港股数据非常全不仅有实时行情还有新闻、基本面、衍生品数据质量没话说。但报价是按年计算的五位数的美元起步而且接入环境通常要求专线或者特定终端协议也不是面向个人开发者的。我的建议是除非你所在的公司或者研究团队预算充足否则个人完全不建议走这条线。大部分个人项目需要的实时行情精度互联网券商那类接口已经覆盖了。2.4 免费网页接口应急可以用长期算了再补充一类大家最常搜到的免费网页接口。像腾讯财经、新浪财经的港股行情接口网上随便一搜就有拼接URL和解析代码。坦白说用来做数据爬虫研究、做日线级别的数据补全很方便毕竟免费。我也用过一段时间用定时任务每分钟抓一次做收盘后的复盘足够了。但它的问题也很明确字段不全、随时改版、IP频率限制。最麻烦的是返回结构经常变动今天还能解析的字段明天就换了位置。这种接口适合应急不适合作为核心功能的数据底座否则你会陷入天天修爬虫的泥潭。2.5 我最终做的选型对比把我试过的四类渠道放在一张表里方便你对照自己的情况数据源类型实时延迟长期费用接入复杂度稳定性盈透证券API亚秒级免费额度超量扣费较高本地网关专用协议高富途OpenAPI亚秒级依赖账户行情权限低SDK封装好高机构级数据商毫秒级按年计费很贵很高专线/专业终端很高免费网页接口秒级到分钟级免费低低随时失效结合我的实际需求个人监控、低频、预算敏感最后选了第2类。互联网券商开放平台的综合体验最符合个人开发者的节奏合法合规、文档完善、有现成SDK、延迟也够用。如果你的账户本身已经开了港股权限那接入成本比你想的低很多。3. 接入一台实时行情源从注册到收到第一条推送3.1 申请接入资格时最容易忽略的事关于注册和申请的细节每家的流程不一样我只强调三个容易被忽略的点。第一一定要区分API接入权限和行情权限是两回事。很多人拿到API Token以为万事俱备结果代码跑通之后发现收来的全是延迟数据。原因大概率是账户没有单独开通对应交易所的实时行情权限去交易软件里找到行情权限设置勾上就行。第二注意Token的有效期和权限范围。有些平台的Token分测试和正式测试Token可能只覆盖模拟交易环境不能用于真实行情。正式Token申请之后建议先看清楚它的权限描述避免对接过程中反复排查。第三提前确认模拟环境是否提供真实的实时行情流。我当时在模拟环境里测试代码发现模拟环境的行情推送频率和真实环境有差异有些字段在模拟环境是造出来的假数据不能用来验证你的数据处理逻辑。真实环境的验证还得等正式权限生效后做。3.2 WebSocket订阅协议的核心结构市面上大多数实时行情API的通路都是WebSocket。原因很简单行情是高频变化的HTTP轮询既浪费资源又做不到真正的实时长连接一次连接就可以持续接收推送效率高得多。一个典型的订阅流程是这样的连接服务商提供的WebSocket地址 - 发送鉴权信息 - 发送订阅消息标明要订阅哪几只股票、哪类行情数据 - 服务端开始主动推送。订阅消息通常长这样{ action: subscribe, codes: [00700, 09988, 03690], types: [QUOTE] }action操作类型subscribe是订阅unsubscribe是取消订阅。codes股票代码列表港股一般是用五位数格式前面要补零比如腾讯是00700而不是700。types订阅的数据类型常见有QUOTE报价、ORDER_BOOK盘口、TICK逐笔成交。不需要的别乱订阅一是浪费你的处理资源二是有些服务商按类型收费。有些服务商支持增量订阅也就是在已有订阅基础上追加代码有些不支持需要全量订阅替代旧订阅。你拿到文档后第一件事就是确认它的订阅是覆盖式还是增量式。3.3 推送消息的字段解析服务端推过来的行情消息各家字段名不一样但核心内容是大同小异的。我拿一个通用化的JSON示例来说明{ event: push, data: { code: 00700, last_price: 310.2, prev_close: 305.5, open: 309.8, high: 312.4, low: 308.1, volume: 12345678, turnover: 38423456.78, bid_price: 310.1, bid_volume: 8000, ask_price: 310.3, ask_volume: 5000, timestamp: 1699999999 } }这里有几个容易踩坑的细节volume通常是成交股数不是成交笔数。turnover是成交额单位是港元。timestamp有的服务商给的是秒级Unix时间戳有的是毫秒级你收到之后第一件事就是确认好单位否则后面算时间差全错了。prev_close是前收盘价open/high/low是当日的开高低这三个值在程序重启之后需要特别注意第4章会详细说。3.4 最小可运行的Python订阅脚本下面给一个用Python接入这类WebSocket行情API的最小示例。我用的是websocket-client库这也是大多数SDK底层会用的库。import json import time import websocket API_URL wss://你的服务商-websocket地址 TOKEN 你的-access-token def on_message(ws, message): data json.loads(message) if data.get(event) push: quote data[data] print(f{quote[code]} 最新价: {quote[last_price]} 时间: {quote[timestamp]}) def on_open(ws): # 先鉴权再订阅 auth { action: auth, token: TOKEN } ws.send(json.dumps(auth)) time.sleep(1) # 给鉴权一点时间 subscribe { action: subscribe, codes: [00700, 09988], types: [QUOTE] } ws.send(json.dumps(subscribe)) def on_error(ws, error): print(f连接异常: {error}) def on_close(ws, code, reason): print(f连接关闭: {code} {reason}) ws websocket.WebSocketApp( API_URL, header{Authorization: fBearer {TOKEN}}, on_messageon_message, on_openon_open, on_erroron_error, on_closeon_close ) ws.run_forever()这个脚本跑起来之后屏幕上会不断打印实时价格。注意两点第一on_open里发送消息后不要做耗时的同步操作。有些服务端要求鉴权后立刻订阅间隔太久会把连接断开。用time.sleep(1)问题不大但如果你的逻辑复杂建议用异步方式等鉴权结果。第二on_message回调函数里不要做重操作比如写数据库、发HTTP通知。因为WebSocket的消息接收是单线程串行的你在回调里卡住了后续消息全部排队延迟会越堆越高。我通常是回调里只做解析然后把解析完的数据扔进队列另一个线程负责消费。4. 真实的坑断线、限流、停牌除权4.1 长连接为什么会断线该怎么重连WebSocket长连接本身并不像看起来那么长。我跑下来最常见的断线原因有三个网络设备NAT超时尤其是家用宽带和云服务器之间的链路、服务端对空闲连接的心跳超时、以及Token过期被服务端主动踢下线。解决断线的思路分两层。第一层是心跳保活。大部分服务端会发送ping/pong帧你的客户端库会自动响应但如果你发现某家服务端不发心跳就需要自己在应用层定时发ping保持活跃。第二层是断线重连。市面上所有的WebSocket客户端都不会帮你无限重连你要自己写重连逻辑。推荐的做法是指数退避重连第一次断开等1秒第二次等2秒第三次等5秒最多等到30秒封顶避免服务端还没来得及恢复就疯狂重连把它打挂。同时要设置一个最大重试次数超过就发告警通知你人工介入。def run_with_reconnect(): delay 1 max_delay 30 while True: try: ws create_ws_app() # 上面的WebSocketApp ws.run_forever() except Exception as e: print(f连接断开原因: {e}) time.sleep(delay) delay min(delay * 2, max_delay)重连成功之后之前订阅的代码不会自动恢复需要重新走一遍订阅流程。所以比较好的做法是把订阅逻辑拆成独立函数重连时调用同一个函数保证状态一致。4.2 一次性订阅太多代码会触发限流我犯过一个很蠢的错误想监控整个自选股列表一次性往订阅消息里塞了200只股票结果服务端直接拒绝了订阅请求返回一个订阅数量超过上限的错误码。后来查文档才知道实时行情订阅通常有并发上限有的一批最多订50个有的一批最多订100个。正确的做法是把股票代码分批订阅每批之间留一点间隔。如果你的自选股数量非常大超过服务商给出的总订阅上限就只能做代码池管理优先订阅持仓和重点关注的股票其他的一律用延迟行情兜底。代码格式也是个大坑。港股代码统一是5位数字很多人习惯写700结果服务端一直没响应浪费很久排查时间。养成好习惯代码不带后缀符合00700这种全数字格式。4.3 停牌、除净与复牌带来的数据陷阱实时行情推送看起来只是一直报数字但港股市场有很多特殊的日子会让数据变得不正常。停牌的时候last_price会停留在停牌前的价格volume也不再增加。如果你的监控脚本只看价格超过某个阈值就报警那么停牌股不会触发任何变化。但如果继续用旧数据计算涨跌幅容易在复牌瞬间产生一次剧烈的假信号。除净日更需要注意。一只股票除净那天理论价格会向下跳一个幅度这个跳空不是市场行为而是权益调整导致的。你如果用昨收价直接计算今日涨跌幅会看到一个巨大的负值但实际可能是除净日的正常调整。处理方式是优先使用服务商推送的prev_close因为除净日服务商一般会修正这个值而不是自己硬算。复牌集合竞价那几分钟成交量可能是平时的几十倍如果你在做分钟K线合成会把那根K线的volume标得异常巨大。我做过的一个统计脚本就因为这把量比指标全污染了。后来我在合成分钟K线前加了一道校验如果当前时间离集合竞价太近且成交量出现异常倍数放大标记为待复牌观察不进入统计。4.4 程序重启后必须重新拉取当日快照前面提到过open/high/low这几个字段它们代表当日的开盘价、最高价、最低价。如果你程序跑在交易中挂掉了重启之后重新订阅新收到的推送只会包含从订阅时间点往后的新数据那当日的开盘价、最高最低价你是不知道的。最典型的反面教材凌晨重启的监控任务日志里当日最高价永远是从凌晨到现在的最高价完全漏掉了早盘开盘那一段行情。解决办法很明确每次程序启动、完成鉴权之后先调用服务商的历史快照接口拉一次当日行情快照拿到open/high/low/prev_close把基础状态补上再开始订阅实时推送。如果服务商没有历史快照接口退而求其次的做法是每天收盘之后把当天的行情汇总数据落库第二天开盘前用落库数据预填充。每次重启都从零开始接收数据并且强行依赖自己的本地累计是我见过最多的数据缺失原因。5. 行情接到手以后我实际做的几个应用5.1 价格异动监控行情到通知的链条实时行情跑通后第一个能立刻落地的是价格异动监控。比如我盯着一只股票希望它在1分钟内涨跌幅超过1%时立刻通知我靠人工盯盘是做不到的而延迟行情又来不及。实现逻辑非常简单维护一个上一次价格的内存字典每次收到推送就对比本次价格和上一次价格的差值超过阈值就触发通知。通知我用的方式是Webhook推送到群聊相当于一个自己搭建的轻量级短信提醒。这里再次提醒在on_message回调里直接发HTTP通知是坏事回调是串行处理的一次通知卡1秒后续所有行情推送全部积压。正确做法是回调里只往队列放事件另一个线程处理通知逻辑。5.2 盘口数据记录把买卖力量留存下来第二个应用是盘口数据的落库。实时行情推送里带着买卖五档的价格和数量这些数据转瞬即逝但它对复盘很有价值。我的做法比较朴素把每次推送的五档数据bid_price/bid_volume/ask_price/ask_volume直接追加到一个SQLite里。收市之后跑一段简单的SQL统计一天内买盘和卖盘的累计数量变化率、大单出现频率就能很直观地看出某只股票当天的资金博弈情况。这个功能用免费网页接口完全做不了因为那些接口没有盘口字段。如果你要记录的数据量比较大记得定期清理旧数据把超过90天的信息压缩或者删除否则SQLite文件会越滚越大查询性能下降。5.3 把行情接进自己的量化框架更进一步可以做一个实时行情到策略信号的管道。最精简的架构是行情推送 - 队列 - 合成器把实时tick合成1分钟/5分钟K线 - 策略引擎 - 信号输出合成器的核心逻辑是收到一条推送把它的时间戳和成交量累加到当前K线上一旦时间戳跨过一个分钟边界就把当前K线封存、交给策略引擎同时开启新K线。这里有一个关键纪律时间戳必须用行情服务端推送的timestamp不要用本机当前时间。我之前贪方便直接用datetime.now()给K线打时间戳结果服务器时钟快了几十秒分钟K线的对齐全部错位策略信号乱成一团。等你踩过这个坑你就明白行情数据的时间基准永远是交易服务器说了算。5.4 一个容易被忽视的合规边界最后说一个很多人不当回事的合规问题实时行情数据是有版权的。你拿OpenAPI这类接口的数据自己看、自己做研究完全没问题。但如果你把这些数据通过你自己的网站、公众号、小程序对外展示甚至做成付费内容卖给其他人就涉及到行情数据的再分发这在授权条款里通常是被严格禁止的。简单来说数据源接口给你个人使用不是给你转卖的。接口服务商对这方面盯得比较紧一旦发现异常调用轻则封Token重则走法务流程。我自己做那个盘口复盘工具的时候特别确认过使用范围只用于个人分析不开放给他人访问。现在回看整个过程最花时间的其实不是写代码而是选型和对数据本身的理解。花了一个多星期接触各种接口之后我才确定适合自己的数据源剩下的接入和调试反而只用了两三个小时。如果你正准备做类似的事情我的建议是开工之前先按文章第1章的思路把你需要的行情类型、延迟等级、预算范围梳理清楚再决定走哪条路。少走弯路比找到一个接口本身更值钱。