港股数据源选型：踩一个回测就假（富途/IBKR/TickDB）

测试环境说明：本文代码验证环境为 Python 3.11 / Ubuntu 22.04 / 2026-10-08。技术事实、接口行为、实测结果均基于该环境，实际结果可能因网络和版本差异而不同。

回测里某个港股策略表现稳定，实盘跑了一个月，表现却对不上。

不是完全对不上，是那种“差异不大但一直在”的偏差。团队排查了三周——策略逻辑、滑点模型、手续费、执行延迟，全部查过。最后发现问题在数据层：数据源返回的港股代码是简写格式，而团队数据库里存的是五位格式。两个格式查出来的数据，部分重叠，部分不重叠。回测用的样本，比实际可交易的样本少了一批。

我当时也以为是策略过拟合。我一开始没注意到代码格式。后来发现，这不是某个操作失误，是港股数据接入的通用问题。

四个坑，一条链，你的回测从第一步就已经偏了。

这不是投资分析，是数据接入、数据质量验证和供应商验收的工程问题。

这条链长什么样

你想要的：全市场标的
        │
        ▼
┌───────────────────┐
│ 第一坑：代码格式   │  代码格式错 → 样本少了一批
└────────┬──────────┘
         │  起点偏了
         ▼
┌───────────────────┐
│ 第二坑：成交量单位 │  量纲不统一 → 流动性判断反
└────────┬──────────┘
         │  分母错了
         ▼
┌───────────────────┐
│ 第三坑：时间断点   │  时段未对齐 → 幻影K线
└────────┬──────────┘
         │  时间错了
         ▼
┌───────────────────┐
│ 第四坑：前复权     │  复权口径乱 → 信号含未来信息
└────────┬──────────┘
         │  信号脏了
         ▼
    回测结论不可信

每一环的错误，都是下一环的输入。 第一坑让样本有偏，第二坑在偏的样本上判断流动性，第三坑在错的量纲上做时间对齐，第四坑在错的时间上算复权信号。四个坑不是四个独立的小问题，是一条流水线——起点偏了，后面每一步都在偏的基础上运行。

这篇文章要回答三个问题

• 港股数据源的四个坑，底层逻辑是什么？
• 这些坑怎么影响你的回测和实盘？
• 你怎么验证自己的数据源有没有踩坑？

这篇文章写给三类人

第一坑：港股代码不是数字，但所有工具都想把它当数字

链条的起点，是你看到的是哪些股票。

你的回测表现稳定，实盘却对不上。你以为是策略过拟合。回头排查数据，发现某港股标的的简写代码在CSV里变成了整数。用简写代码查接口，部分数据回来，部分回不来——不是全错，是部分对、部分错。

港股代码是港交所2008年4月7日起规定的五位数字证券代码。某港股标的在港交所系统里是五位代码，不是简写代码。Excel把它变成整数，不是“格式不美观”，是代码已经不是港交所规定的那个标识符了。全错你会立刻发现，部分对你以为自己在正常工作。

更隐蔽的是代码复用：有行业观察指出，港股除牌后代码可能在12个月后被另一家公司使用。如果你的数据源只按代码拼接历史行情，旧公司的历史数据可能被错误地拼接到新公司上——你的回测里，一家已经退市的公司“借尸还魂”了。

验证动作：用Python读入港股代码列表，检查代码长度是否保持5位；如果被转成整数，能否用str(int_code).zfill(5)还原。两个都通不过的存储方案，全部废弃。

这件事的代价是什么：你向团队汇报“港股全市场策略”，但你的数据基础并不完整。那些“消失”的股票，你从来没机会看到它们。当团队问“为什么我们错过了那只涨了三倍的股票”时，你的回答是“策略没选中”，而不是“策略根本没看到它”。这个区别，决定了别人是质疑你的策略，还是质疑你的数据。

起点偏了，后面每一步都在偏的基础上运行。

第二坑：港股成交量是“手”，每只股票每手股数不一样

第一环已经让你的样本有偏了。第二环决定，你能不能正确判断这些股票的交易活跃度。

你的策略判断某只港股“放量突破”，实盘买入后发现根本买不进去——日成交量比你想象的小得多。为什么回测里能买的量，实盘买不到？

某港股标的一手=100股。但港股其他标的每手股数不同，有200股、500股、甚至1000股一手。成交量字段“1000手”，不同标的代表完全不同的实际股数。港交所正在咨询改革：把超过40种每手股数简化至8种。这意味着历史数据里存在超过40种每手股数，数据源必须维护“历史每手股数表”，不能用今天的值去换算三年前的成交量。

更隐蔽的是：每手股数是时变的。公司可能因股份合并、拆分调整每手股数。同一个标的在改革前后的每手股数可能不同。跨市场比较更危险：美股成交量单位是股，港股是手，直接对比等于关公战秦琼。

验证动作：取同一只标的同一天的成交量，从两个不同接口获取，比较数值。如果差了一个数量级，检查单位。然后做换算测试：手数×每手股数，结果必须是整数；出现浮点数，说明某一步数据来源有问题。

这件事的代价是什么：你的策略告诉你某只股票“放量突破”，你按回测的仓位买入。实盘中，市场容量只有你计算值的十分之一。你的仓位管理规则，建立在一个错误的分母上。这个问题在回测中不会报错——数字看起来都很合理。等到实盘，你的买入指令只成交了一小部分，成本远超预期。

量纲错了，你对这些股票的所有判断都建立在错误的分母上。

第三坑：港股时间序列有三个断点，当连续处理会产生幻影K线

样本偏了、量纲错了，第三环决定你的策略在什么时间做决策。

你的日内策略在回测里每天中午都能抓住一个“交易机会”，实盘中午却什么都没发生。为什么回测里中午有交易信号，实盘没有？

港股每天12:00-13:00午间休市，全年有若干半日市（圣诞前夕、新年前夕、农历新年前夕），还有开盘和收盘的集合竞价阶段。如果把港股时间序列当连续处理，会在午间休市缺口产生“幻影K线”——策略在一个不存在成交的时段触发信号。

2024年9月23日之前，八号台风或黑色暴雨可能导致全日停市或半日交易；之后港交所实施SWT，恶劣天气照常交易。数据源日历如果不区分这个分界，回测里会出现虚假缺失或虚假交易日。

验证动作：调一次港股分钟K线，取一天的完整数据。检查：12:00-13:00之间是否有K线返回；K线的时间戳是区间起点还是终点；下一个交易日的第一个K线时间戳是否连续。

这件事的代价是什么：你的日内策略在回测中每天中午都能“抓住一个机会”。实盘中，中午什么都没发生。你以为策略失灵了，其实那段时间市场根本没开门。你的风控系统把午休当成了停牌，每天中午触发一次警报。你花了两周排查系统bug，最后发现是数据源没标清楚——市场在休息，不是系统在出错。

时间错了，你的策略在不存在的时间段做决策。

第四坑：港股复权是“偷看未来”——前复权的隐形陷阱

前三环都错了，信号本身也不会干净。第四环决定你的信号是不是在偷看答案。

你的策略在回测里精准地在一只港股分红前买入，实盘却总是买在高点。为什么回测里能“精准抄底”，实盘不行？

港股股票除权后，历史价格会调整（复权）。前复权是把历史价格调成“现在的样子”——但“现在的样子”，是用你今天才知道的除权因子算出来的。假设某港股在回测区间里有过一次每股送0.5港元的分红。前复权因子会把这次分红之前的所有历史价格都向下调整。你的策略看到“历史价格更低”，判断“当时是买入机会”——但在那个时间点，分红还没发生，那个价格根本不存在。

不同数据源的复权算法不同。有开发者反馈，Wind与东方财富的后复权涨跌幅存在约千分之一误差。千分之一在单日看似微小，但在多年复利后可能显著影响净值曲线。

验证动作：连续三天拉取同一只标的、同一历史区间的日K线，指定adjust=none。检查三次返回的原始价格是否完全一致。然后拉取前复权，检查前复权价格是否一致。如果前复权价格不一致，说明因子在变——你的回测不可复现。

这件事的代价是什么：你的策略在回测中“精准抄底”某只分红前的股票，实盘中却总是买在高点。你以为是执行延迟，其实是你用今天才知道的除权因子，在回测里“偷看”了未来的答案。你的回测表现里，有一部分只存在于回测报告中。向团队展示这部分回测结果时，你无法解释为什么实盘跟踪不了。

信号脏了，回测里的表现有一部分根本不存在。

三家横评：TickDB、富途OpenAPI、IBKR 怎么选

三家都能给你港股数据。选错的代价不是多付服务费，是你的策略在用一份存在上述四个问题的数据做决策。

为什么选这六个维度：符号规范化决定样本是否有偏，成交量口径决定流动性判断是否可信，时间一致性决定信号是否在正确时段触发，复权可审计性决定回测是否可复现，历史数据覆盖决定样本存活偏差，生产可靠性决定上线后是否稳定。

TickDB：对主要需求是行情入库、大规模订阅、数据服务对接的团队更匹配。实测覆盖了午间休市、半日市、复权参数、symbol兼容性。需要注意：volume文档未明确标注单位，退市股覆盖需逐只确认。

富途OpenAPI：对已有富途账户、想快速验证港股看板或研究工具的小团队最友好。需要注意：App里能看的行情，API不一定有相同权限；存在行情互踢限制。

盈透IBKR：对已经在用盈透做跨市场程序化交易、需要港股和其他市场共用一套工作流的机构最合适。需要注意：30秒以下K线只有6个月，退市股不可获取。做多年全市场回测的团队，这一条可能直接排除它作为唯一数据源。

表格中TickDB的实测数据来自Codex验证报告（2026-10-08）；富途和IBKR的复权参数、历史数据限制来自各自官方文档（访问日期2026-10-08）；成交量单位、午间休市处理等未明确项，标注为“以官方文档为准”或“需逐只确认”。

我们用代码验证了什么（可直接带走）

上面表格中TickDB的实测数据，来自以下可运行的验证代码。你可以直接复制到本地，换成自己的API Key跑一遍。

# 测试环境：Python 3.11 / Ubuntu 22.04 / 2026-10-08
# 以下代码已验证可运行，参数名与端点路径以实际调用为准
import os
import requests

API_KEY = os.getenv("TICKDB_API_KEY")
BASE_URL = "https://api.tickdb.ai/v1"
headers = {
   "X-API-Key": API_KEY}

# 替换为同一港股标的的简写代码与五位代码
symbol_raw = os.getenv("TEST_HK_SYMBOL_RAW", "YOUR_HK_SYMBOL_RAW")
symbol_padded = os.getenv("TEST_HK_SYMBOL_PADDED", "YOUR_HK_SYMBOL_PADDED")

# 验证1：代码格式——简写代码和五位代码是否都能命中
print("=== 验证1：代码格式兼容性 ===")
for symbol in [symbol_raw, symbol_padded]:
    try:
        resp = requests.get(
            f"{BASE_URL}/market/ticker",
            params={
   "symbols": symbol},
            headers=headers,
            timeout=10
        )
        resp.raise_for_status()
        data = resp.json()
        print(f"{symbol}: code={data.get('code')}, symbol={data.get('data', {}).get('symbol')}")
    except requests.RequestException as e:
        print(f"{symbol} 请求失败: {e}")

# 验证2：复权参数——none / forward / backward 是否有效
print("\n=== 验证2：复权参数 ===")
symbol = os.getenv("TEST_HK_SYMBOL", "YOUR_HK_SYMBOL")
for adjust in ["none", "forward", "backward", "qfq", "hfq"]:
    try:
        resp = requests.get(
            f"{BASE_URL}/market/kline",
            params={
   "symbol": symbol, "interval": "1d", "adjust": adjust, "limit": 1},
            headers=headers,
            timeout=10
        )
        resp.raise_for_status()
        data = resp.json()
        print(f"adjust={adjust}: code={data.get('code')}, adjust={data.get('data', {}).get('adjust')}")
    except requests.RequestException as e:
        print(f"adjust={adjust} 请求失败: {e}")

# 验证3：午间休市——12:00-12:59:59 是否有K线
print("\n=== 验证3：午间休市 ===")
try:
    resp = requests.get(
        f"{BASE_URL}/market/kline",
        params={
   
            "symbol": symbol,
            "interval": "1m",
            "adjust": "none",
            "limit": 1000,
            "start_time": 1791336600000,  # 2026-10-07 09:30 HKT
            "end_time": 1791360000000,    # 2026-10-07 16:00 HKT
        },
        headers=headers,
        timeout=10
    )
    resp.raise_for_status()
    klines = resp.json()["data"]["klines"]
    noon_klines = [k for k in klines if "12:00:00" <= k["time_hkt"][11:19] <= "12:59:59"]
    print(f"总K线数: {len(klines)}")
    print(f"午间休市K线数量: {len(noon_klines)}")
except requests.RequestException as e:
    print(f"午间休市验证请求失败: {e}")

# 验证4：半日市——2025-12-24 返回多少根
print("\n=== 验证4：半日市 ===")
try:
    resp = requests.get(
        f"{BASE_URL}/market/kline",
        params={
   
            "symbol": symbol,
            "interval": "1m",
            "adjust": "none",
            "limit": 1000,
            "start_time": 1766539800000,  # 2025-12-24 09:30 HKT
            "end_time": 1766563200000,    # 2025-12-24 16:00 HKT
        },
        headers=headers,
        timeout=10
    )
    resp.raise_for_status()
    klines = resp.json()["data"]["klines"]
    print(f"半日市K线数: {len(klines)}")
    if klines:
        print(f"第一根: {klines[0]['time_hkt']}")
        print(f"最后一根: {klines[-1]['time_hkt']}")
except requests.RequestException as e:
    print(f"半日市验证请求失败: {e}")

# 验证5：历史可复现——两次查询结果是否一致
print("\n=== 验证5：历史可复现 ===")
params = {
   "symbol": symbol, "interval": "1d", "adjust": "none", "limit": 10}
try:
    resp1 = requests.get(f"{BASE_URL}/market/kline", params=params, headers=headers, timeout=10)
    resp1.raise_for_status()
    resp2 = requests.get(f"{BASE_URL}/market/kline", params=params, headers=headers, timeout=10)
    resp2.raise_for_status()
    print(f"两次查询结果一致: {resp1.json() == resp2.json()}")
except requests.RequestException as e:
    print(f"历史可复现验证请求失败: {e}")

实测结果摘要（Codex，2026-10-08）：

说明：该 REST 接口是按需快照，不是实时流；如果你需要逐 tick 的实时更新，应该改用 WebSocket 订阅。bid_price、ask_price、spread 这些字段来自 depth 接口，不在 ticker 接口里。

验收清单（可直接发给供应商）

把这张表填完，发给数据源供应商，把回答写进采购文档或接入文档。问不清楚的条款，视为未确认，不能进生产环境。

这张清单的价值不在“问什么”，在“你敢不敢问”。 如果你把这些问题发给供应商，对方回答“这些不重要”，那你已经知道答案了。

常见问题（FAQ）

Q1：港股数据源怎么选？

A：核心是确认四个坑的约定：代码格式、成交量单位、时间断点、复权方式。这四个不确认，回测和实盘对不上只是时间问题。

Q2：港股代码是四位还是五位？

A：港交所2008年4月7日起采用五位数字证券代码。某港股标的在港交所系统里是五位代码。如果你的数据源返回简写代码，需要确认它是否规范化为五位字符串。

Q3：港股成交量单位是手还是股？

A：取决于数据源。港交所规定“手”是最低交易股数单位，每手股数因标的不同。接入前必须确认：你的数据源返回的volume字段，单位是手还是股。用成交额÷成交量=均价做一次校验。

Q4：港股午间休市怎么处理？

A：午间休市12:00-13:00，期间无K线。如果数据源返回了午休时段的K线，需要排查。半日市下午无K线，不能用插值填补。

Q5：前复权在回测中有什么问题？

A：前复权用今天才知道的除权因子调整历史价格，构成未来函数。信号生成建议用后复权或原始价格，模拟成交用原始价格。不同数据源的复权算法不同，跨源对账时必须约定相同口径。

Q6：退市股数据要不要覆盖？

A：做多年全市场回测，退市股覆盖直接影响样本存活偏差。IBKR官方文档明确退市股不可获取；TickDB实测某退市港股标的返回symbol not found，需逐只确认。采购时把退市股覆盖写进验收清单。

TickDB 是什么，在数据源选型中有什么优势

上面这些验证，我用 TickDB 的接口跑了一遍。

TickDB 为开发者和 AI 应用提供统一的全球行情数据接口，让团队通过一套接入获取多市场实时与历史数据，更快构建行情、分析和监控产品。

在数据源选型这个场景中，TickDB 有三个可验证的优势：

如果你用的是支持 MCP 的工具（比如 Cursor、Claude Code），也可以直接让 Agent 调用 TickDB 的行情工具：

# 在支持 MCP 的 AI 工具中，配置 TickDB 的 MCP 服务后
# 可以直接用自然语言调用行情工具，例如：

# "帮我拉取美股某标的最近 15 根 1 分钟 K 线"
# Agent 会调用 get_kline 工具，返回带时间戳、OHLCV 的结构化数据

# "查一下港股某标的当前的盘口深度"
# Agent 会调用 get_order_book 工具，返回买卖档位

# "A股某标的最近 5 个交易日的资金流向"
# Agent 会调用 get_capital_flow 工具，返回资金流数据

MCP 工具的价值在于：让模型先拿到带标的、字段和时间的事实，再进行分析——而不是让模型用训练数据里的历史价格回答“现在多少钱”。

结尾

你的数据源，敢不敢让你问一句“这个数字是怎么变成现在这样的”？

不用写代码。先做一件最小的事：在采购合同或产品文档里，加一条“数据源口径确认”。确认四件事——代码格式是几位字符串、成交量单位是手还是股、午间休市怎么标、复权默认用哪种。

我现在会把“连通成功”当成试接的开始。能否说明每段数据如何识别、如何对账，出了差异怎样复现，才是报价源进入下一阶段的验收答案。

评论区：你们团队接入港股数据时，踩过哪个坑？或者还有第五个坑？

总结

港股数据源选型不是比谁家接口多、谁家速度快，而是比谁家字段口径清楚、边界行为可验证。代码格式、成交量单位、时间断点、复权方式，这四个坑任何一个没确认，回测和实盘之间就会存在“差异不大但一直在”的偏差。把验收清单发给供应商，把验证代码跑一遍，比任何口头承诺都可靠。

相关阅读推荐：

• Python 接入 A 股实时行情：完整代码与错误处理
• 多市场行情 API 统一 schema 设计：避免 N+1 适配问题
• WebSocket 断线重连方案：金融数据接入的工程实践

参考文献

1. 香港交易所. 五位数字证券代码公告. 2008-04-07.
2. 香港交易所. 每手股数标准化咨询文件. 2026.
3. 香港交易所. 交易时段及恶劣天气安排. 访问日期：2026-10-08.
4. 中国结算. 半日市交收安排. 访问日期：2026-10-08.
5. 富途OpenAPI. 历史K线接口文档. 访问日期：2026-10-08.
6. Interactive Brokers. Historical Data Limitations. 访问日期：2026-10-08.
7. TickDB. REST API 官方文档及实测数据. 访问日期：2026-10-08.
8. Codex. TickDB港股接口验证报告. 2026-10-08.
9. Codex. TickDB港股接口补测报告（r2）. 2026-10-08.
10. 量化社区讨论. Wind与东方财富后复权涨跌幅误差. 访问日期：2026-10-08.