港股投资者必备：三大数据源对比，哪种最适合实时行情与回测？

港股投资者必备：三大数据源对比，哪种最适合实时行情与回测？

想做一个港股自选股看板，或者回测一套港股策略，第一步往往都是找数据接口。可等到真正开始接入，问题就变得具体了：拿到的是最新报价，还是正在变化的日 K 线？成交量已经是"股"，还要不要乘每手股数？历史数据缺了一段，是休市、停牌，还是接口只返回了部分记录？

这些问题会直接影响选型。看板重视更新方式与失效识别，回测重视历史覆盖、字段口径和可复现性。 同一份"支持港股"的功能说明，未必能同时回答两类需求。

本文选择富途 OpenAPI、盈透证券（IBKR）API 和 TickDB，比较港股行情与价格策略回测所需的数据能力。前两者与券商账户及交易工具相连，第三种按行情服务接口接入；本文比较的是数据接入，不评价券商交易服务。"三大"仅指本文选取的三个对象，不代表市场份额或行业排名。接口说明核对于 2026 年 10 月 8 日；本文是文档与工程方法对照，没有进行三家同条件延迟测试。

一、先分清你需要哪一种"实时"

如果页面每隔一段时间刷新最新价格，需求首先是行情快照 ：每次请求拿到查询时刻附近的状态。如果价格变化要驱动告警或更新本地状态，需求则是持续推送：建立连接、订阅标的，再逐条处理后续消息。

还有一种常被混在里面的数据：实时日线。它描述开盘以来正在形成的开高低收和成交统计，不等于逐笔成交流，也不能还原盘中每次价格变化的先后顺序。

回测面对的是另一项要求：策略在某个历史时刻作判断时，哪些数据已经确定。上午使用当日最终收盘价，或者把当天最终成交量带入上午的筛选条件，即使数据完全准确，也会产生未来信息。

因此，先把任务写成一句能验收的话。例如："跟踪 30 只股票，在数据过期时停止触发告警"，或"保存指定三年区间的日线和复权依据，能够重复运行同一份回测"。有了这句话，才知道接口缺了哪项能力会影响项目。

二、三种方案分别适合从哪里开始

富途 OpenAPI：适合从已有港股工具链开始验证

富途提供报价、逐笔、摆盘和 K 线等行情接口。选择 OpenD + SDK 路径时，需要运行并登录 OpenD，再由程序连接网关、订阅和处理推送。当前官方门户也列出了免网关 REST 接入，因此不宜笼统地说"富途只能通过本地网关使用"；不同路径应按对应文档分别核验。富途接入路径、行情接口总览

如果已经使用富途，并准备把港股看板、研究程序与现有工具衔接起来，这是一条值得先试的路径。但 App 里能看的行情，不代表 API 一定有相同权限 。富途文档将行情权限、订阅额度、历史 K 线额度分别说明；接入前要核对自己的账户，而不是引用别人的免费权益作为保证。权限与额度

历史侧，OpenD 的 request_history_kline 支持区间查询和分页。文档列出的分钟 K 线范围为近 8 年、日 K 线为近 20 年，同时存在按标的计算的历史额度。这个范围描述不能代替逐证券的实际覆盖检查。批量回补时，既要处理 page_req_key，也要安排标的额度和请求频率。历史 K 线接口

盈透 IBKR：适合已有账户的跨市场程序化工作流

如果已经在使用盈透，希望让港股和其他市场共用一套程序化工作流，IBKR 值得纳入候选。其 TWS API 通过 TCP Socket 连接 TWS 或 IB Gateway；另有 Web API 路径，不能把两套接口的认证、会话和限频混在一起。TWS API 介绍、Web API 说明

选型时要确认的不只是"有没有 API"，还有对应用户名是否具备所需行情订阅、程序使用的是哪种会话，以及实时数据还是延迟数据。IBKR 官方说明，多数证券通过 API 获取行情需要相应的 Level 1 订阅；具体港股品种及深度需求仍要按账户权益核对。API 行情订阅要求

历史回测则要更谨慎：官方列有不可获取的数据类别，例如超过六个月的 30 秒及以下 K 线，以及已不再交易证券的数据。不能把这条小周期限制误写成"所有分钟线只能查六个月"，但也不能因为能查当前股票，就推断退市样本同样齐全。对需要历史全市场样本的策略，这可能决定是否还要补充独立研究数据。历史数据缺口说明

行情服务接口：先明确数据任务，再验证运行边界

如果项目主要负责看板、扫描和数据落库，可以把行情接入单独作为一个模块来选择。接口能返回当前价格、能推送更新、能查询历史区间，是三项不同能力；不应拿其中一项代替另外两项。

下面将三种候选放在同一张图中，分别列出接入路径和必须验证的条件。场景选择是依据接口形态作出的建议，不是延迟、稳定性或价格排名。

图 1：三种接入方案的路径与条件。实际权限、数据覆盖与运行表现需要单独验收。

推送应用还要区分"恢复最新状态"与"补回断线期间全部事件"。看板可能只需要恢复最新价；逐笔研究则需要明确的事件补偿机制。恢复连接本身不能证明两者都已完成。

三、按现有条件选择试接顺序

你的主要任务	可以优先验证的路径	决定能否采用的条件
已有富途账户，制作港股看板或研究工具	富途 OpenAPI	选定路径可部署，API 权限与订阅额度满足需求
已有盈透账户，需要跨市场程序化衔接	IBKR 对应 API	行情订阅、会话管理、合约识别及历史覆盖达标
主要需求是行情入库、看板与数据服务对接	图 1 中的行情服务接口	订阅规模、区间查询、字段口径与断线恢复满足要求
多年全市场回测，包含退出市场的证券	逐一核验候选的数据覆盖	样本范围和公司行动数据齐全，不能只看现存股票

已有账户可能减少部分接入步骤，但不自动意味着最低成本；不需要交易功能，也不意味着任一独立行情接口都能满足全市场历史研究。应把行情权益、订阅规模、历史回补量和维护成本一起计算。

数据也可以组合使用，但应保存来源。使用一家实时行情、另一家历史 K 线时，只有先对齐标的、统计窗口和复权口径，才有资格把差异解释为质量问题。

四、港股回测前，先拦住四类错误

1. 股票代码、市场和币种要一起保存

同一证券在不同接口里可能采用带前导零的代码、市场后缀或另一种标准格式。不要让表格软件先把代码转成整数，再靠补零猜回原始标识。建议保留原始代码，并通过证券主表映射到内部标识。

主表还应包含证券类型、上市状态、计价币种和交易单位。对 IBKR 这类使用合约对象的接口，不能只把别家的字符串代码换个格式，就认为已经定位同一证券；应核对合约标识、市场与币种，并保存映射。

对跨市场组合尤其如此："元"是金额尺度的一部分，不能单凭这个字就判定是人民币。先保留原币金额；需要换算时，再明确汇率来源、对应日期与换算时点。

2. 成交量字段与每手股数分开处理

每手股数是证券属性，成交量单位是接口字段属性。只有字段明确以"手"计量时，才需要用对应交易单位换算；已经以"股"计量的值，不能再乘每手股数。适配规则应绑定到具体接口和字段，而不是给所有港股数据统一乘上一个固定数字。

下面用模拟输入演示一个严格的转换函数。只有来源明确声明单位为"手"，且已经取得对应证券、对应日期的每手股数时，才允许换算。示例中的 500 是假设值，不指向任何真实股票。

from decimal import Decimal

def volume_shares(value, unit, lot_size=None):
    n = Decimal(str(value))
    if not n.is_finite() or n < 0:
        raise ValueError("成交量必须是有限非负数")
    if unit == "share":
        result = n
    elif unit == "lot" and lot_size is not None:
        size = Decimal(str(lot_size))
        if not size.is_finite() or size <= 0:
            raise ValueError("每手股数必须是有限正数")
        if size != size.to_integral_value():
            raise ValueError("每手股数必须是整数")
        result = n * size
    else:
        raise ValueError("单位或对应日期的每手股数未确认")
    if result != result.to_integral_value():
        raise ValueError("换算后必须是整数股数")
    return int(result)

# 模拟数据，不是供应商返回值。
assert volume_shares("1000", "share") == 1000
assert volume_shares("2", "lot", 500) == 1000

这个函数只处理单位；它不会判断一条记录是否重复，也不会判断成交量究竟是当日累计值还是单根 K 线值。适配表中还应保留统计窗口，不能把累计成交量直接相加当成日成交量。

3. 交易日期相同，不等于统计时段相同

分钟数据应采用港股自身的交易日历和时段规则，单独处理午间休市、半日市及集合竞价；不能用一段连续分钟序列机械补齐全天。缺失分钟要先判断该时段是否应有记录，以及数据源是否省略无成交周期，再决定如何处理。

即使都是 K 线，也要确认描述的是成交价格、买卖报价还是中间价。IBKR 官方排错说明将 TRADES、MIDPOINT、BID_ASK 和时区差异列为图表不一致的常见原因。比较前先保存请求中的数据类型和时段参数，不应仅凭返回字段都叫 OHLC 就逐行相减。IBKR 图表口径排查

记录时间也要拆清楚：源时间、接收时间、交易日期、K 线标签分别保存。把时间戳显示为香港本地时间，只完成了时区转换，还没有确定它代表周期开始、周期结束，还是最近一次状态更新。

4. 复权数据需要版本，回放需要可得时点

复权价格适合连续指标计算，但应保留原始价格、复权方式、可获得的因子或公司行动依据，以及获取日期。一个很容易忽略的细节是：富途 OpenD 的 request_history_kline 默认参数为 AuType.QFQ，即前复权。跨源对账时必须显式指定同一口径，不能假设所有接口默认都返回不复权价格。历史 K 线参数

同时，指标价格与模拟成交价格应分开处理。分红、拆合股和持仓数量变化，需要与价格序列协调，避免既使用已经调整的价格，又重复计入同一次公司行动。是否存在未来信息，要看策略在当时使用了什么数据，不能只凭"前复权"三个字下结论。

图 2：港股数据入库与回放前的核对顺序。此图为方法示意。

五、用一个小样本，把"适合"变成可验证的结论

正式接入前，给各候选方案安排同一份验收任务：选一只交易活跃股票、一段有停牌记录的样本，以及一段覆盖公司行动的历史区间。实时任务连续观察一个交易时段，回测任务固定起止日期、周期和复权方式。

下面是一个获取最近日线的最小请求示例，需要在本机设置有效密钥。端点、鉴权方式和参数已按官方文档核对；本次没有执行线上请求，也不将它作为三家质量比较结果。

: "${TICKDB_API_KEY:?请先设置 API 密钥环境变量}"
curl --fail-with-body --silent --show-error --get \
  'https://api.tickdb.ai/v1/market/kline' \
  -H "X-API-Key: ${TICKDB_API_KEY}" \
  --data-urlencode 'symbol=700.HK' \
  --data-urlencode 'interval=1d' \
  --data-urlencode 'adjust=none' \
  --data-urlencode 'limit=10'

请求返回后，先检查 HTTP 状态、业务 code 是否为 0，再检查 data.klines 的日期范围和内容。请求 10 根不保证返回 10 根；最后一根也可能仍在形成。这个请求未指定起止时间，不能代替目标历史区间的完整性验收。

验收时保留以下记录，才便于解释差异：

• 覆盖记录：逐日期或逐时间窗比较预期集合与返回集合，区分休市、停牌、未上市和采集失败。
• 口径记录：保存原始代码、币种、单位、时段及复权方式，只有对齐后才比较价格和量额。
• 实时记录：保存源时间、接收时间与连接状态。时间语义未确认时，不把两者相减后宣称为端到端延迟。
• 恢复记录：主动中断采集，检查恢复后是否重建应用需要的状态，并单独标注事件缺口。
• 版本记录：保存原始响应、转换规则、因子和查询时间，用相同输入再运行一次，确认结果可以复现。

如果已有富途或盈透账户，可以先从对应 API 验证一个小样本；如果主要建设行情应用，就按数据模块的需求比较接入条件。无论采用哪条路径，长期回测先解决覆盖、口径与版本保存，盘中运行先验证更新语义和故障恢复。

对港股而言，选型不能停在"有没有报价"。把代码、币种、单位、交易时段和复权依据接成一条可追溯的数据链，才知道手里的数据是否足以支持当前任务。