A 股和港股一起回测，先别急着看收益

导读： 跨市场回测中，有一种偏差不来自策略逻辑，也不来自因子选择。它来自 A 股和港股在交易日历上的错位——五一长假、佛诞假期、半日市。本文不讨论策略好坏，只给一套可复用的排查框架，帮你在看收益之前，先把日历对齐。

一位做跨市场策略的朋友，最近分享了他的一段排查经历。

他的逻辑不复杂：在 A 股和港股的龙头公司之间做配对交易，捕捉估值裂口的收敛机会。回测跑三年，曲线看起来不错。

他说：“我觉得逻辑是通的，但一直不太踏实。”

后来他做了一件事——先不看收益，只看交易日。 结果发现问题。

A 股有五一长假，港股有佛诞假期。A 股休市时港股在交易，港股休市时 A 股正常开市。但他的回测脚本用了最省事的 inner join——只保留了两个市场同时有交易的日期。那些单边市场独自波动的日子，在数据清洗阶段就被悄悄删掉了。

策略在回测中捕捉到的部分表现，可能存在一部分由样本删减或对齐假设造成的偏差。 而被删掉的那部分，恰好是实盘中策略必须面对的真实风险。

一句话：回测曲线里那部分让你觉得“策略好像还不错”的东西，有一部分可能是数据剪辑的结果。

问题从哪来：跨市场数据的“隐性断层”

回测里常用的做法，是从不同数据源拉取 A 股和港股行情，本地合并。但很少有人想过：你手头 A 股的交易日历基准、港股的数据采样时刻和本地脚本的对齐规则，是不是同一套逻辑？

当你用的是碎片化数据源时，这个问题会更隐蔽——A 股的数据源用上交所日历，港股的用港交所日历，两个文件的假期规则不同。你用一个 merge 把它们拼在一起，合并逻辑默认帮你丢了哪些、补了哪些，不单独打印根本不知道。

真正的差异往往不在策略，而在上游数据字段的一致性。

这正是需要一个统一数据层的原因。以 TickDB 为例，它把跨市场行情的常见字段命名、复权基准、交易状态标记都统一在同一个 API 里。在接入层就处理掉字段维度不一致的问题，这意味着交易日历对齐、时区转换这类核验工作可以在一个整体框架下进行。排查数据偏差时，不用在三个数据源之间来回确认。

核心问题：错位从何而来？

跨市场策略的交易日历错位，不只是“少了对齐”那么简单。不同处理方式，会从不同方向影响你的回测结果。

一眼看重点： inner join 删单边波动，forward fill 造虚假机会，停牌和休市混淆会直接污染信号。

⚠️ 注意：字段精度、时间单位、采样频率和数据新鲜度是不同概念，不能假设所有接口使用同一 timestamp 精度。当你从不同数据源分别拉取 A 股和港股数据时，这些底层差异会被成倍放大——这也是为什么在排查这类问题时，一个统一字段语义的数据层比事后校验更关键。

五步排查框架

在看收益和归因之前，先走完这五步。不需要复杂工具，你的回测脚本里就能完成。

第一步：确认两地交易日历

获取上交所/深交所和港交所官网的历史休市安排。不要在未核验前直接依赖任何第三方数据源默认的“交易日历”——它可能只覆盖单一市场。建议手动建一个对照表。

第二步：标记单边交易日

在数据里新增一列 market_status：

• BOTH_OPEN — 两地同时交易
• ONLY_A_SHARE — 仅 A 股交易
• ONLY_HK — 仅港股交易

这一步让你立刻看到，回测中有多少天策略实际上只暴露在单边市场里。

第三步：区分三种 join 逻辑的影响

• Inner Join：跳过所有单边交易日。回测假设策略在这些日子没有风险暴露。实盘中能做到吗？
• Outer Join：面对大量缺失值。前向填充意味着在休市日做“静止不动”的假设。这个假设需要检验。
• Forward Fill / Backfill：可能在单边交易日创造出本不存在的持仓变动。把它当作模型假设来审视，而不是数据清洗动作。

第四步：检查日期字段，而不是表面

不要只看 date 列。检查对齐用的索引。如果是时间戳，确认它代表哪个时区的零点。不同数据源的时间戳在精度、采样频率上可能不同——这与“交易日对齐”是两个问题，但同样影响因子可比性。

真实排查场景： 如果你用的是 TickDB 这类统一行情 API，A 股和港股的日线时间戳都已标准化为 UTC，交易状态有结构化标记字段，上述第三步和第四步的检查可以直接落到对比 market_status 列上，而不用分别核验两边数据源的时间定义。但即便数据层帮你统一了结构，join 方式的选择和填充假设依然需要你自己决定——这是策略逻辑的一部分，不是数据源能替你回答的。

第五步：评估绩效指标的稳健性

对比两种处理下的回测结果：

• 仅使用 BOTH_OPEN 日期
• 包含所有交易日（用审慎方式处理缺失）

两者的差异，可作为评估日历错位影响的一个诊断指标，不能直接等同于真实收益差或 Alpha 来源。 这个差值不是要被“优化”掉的噪音，而是你需要理解和管理的策略风险敞口。

教学示例

以下代码演示检查思路，仅作教学参考，不应直接用于实盘。

# 教学示例：跨市场交易日历对齐的预处理检查
# 此代码仅用于解释对齐逻辑，不连接任何真实接口

def build_market_status_table(df_a, df_hk, cal_a, cal_hk):
    """
    基于A股和港股全日期集合，构建交易日状态表
    参数：
        df_a, df_hk: 各市场数据，需含 'date' 列
        cal_a, cal_hk: 各市场交易日历的日期集合
    返回：
        status_df: 包含日期和 market_status 的状态表
    """
    # 第一步：构建全日期集合并标记状态
    all_dates = sorted(set(df_a['date']) | set(df_hk['date']))

    status_records = []
    for d in all_dates:
        in_a, in_hk = d in cal_a, d in cal_hk
        if in_a and in_hk:
            status = 'BOTH_OPEN'
        elif in_a:
            status = 'ONLY_A_SHARE'
        elif in_hk:
            status = 'ONLY_HK'
        else:
            status = 'NON_TRADING'
        status_records.append({'date': d, 'market_status': status})

    status_df = pd.DataFrame(status_records)

    # 第二步：检查若使用 inner join 哪些日期会被丢弃
    both_open = set(status_df[status_df['market_status'] == 'BOTH_OPEN']['date'])
    discarded_a = set(df_a['date']) - both_open
    discarded_hk = set(df_hk['date']) - both_open

    if discarded_a or discarded_hk:
        print(f"警告: 若使用 inner join，将丢弃 {len(discarded_a)} 个A股单独交易日 "
              f"和 {len(discarded_hk)} 个港股单独交易日。")
        print("这些日期上的单边市场波动将在回测中被完全忽略。")

    return status_df

这个脚本的核心意义，不在于“实现”数据合并，而在于强制你看到那行警告。 警告里列出的数字，是你在进入回测前应该停下来审视的风险暴露。

本文不能证明什么

1. 不能证明任何策略有效：交易日历对齐是数据质量的前提性检查，不验证交易逻辑的优劣。
2. 不能证明可以实盘使用：所有方法和示例仅用于揭示回测中一种潜在偏差来源，不构成交易建议。
3. 不能证明某个市场或品种更值得交易：只讨论“对齐”技术问题，不评价任何市场投资价值。
4. 不能替代官方交易日历和真实数据核验：日历信息最终须以交易所官方公告和实际数据记录为准。

跨市场回测的日历错位，本质上不是数据源的缺陷，而是数据使用者在合并不同市场信息时，需要主动做出的工程决策。统一的数据层可以帮你省去反复确认字段语义、时区定义和交易状态标记的重复劳动，让你把精力集中在 join 规则、填充假设这些真正影响策略逻辑的判断上——而不是让数据层的碎片化成为偏差来源。

以 TickDB 为例，它把跨市场行情的字段命名、复权基准、交易状态标记统一在同一个 API 里。这意味着你在排查日历错位时，可以在一套一致的字段体系下工作，而不是在 A 股数据源和港股数据源之间来回对照字段定义。工具的价值在于降低排查的复杂度，但认知决策的最后一个环节——对齐规则的选择、缺失值的处理——永远是你自己的。

免责声明：本文仅讨论量化策略的数据接入技术与回测方法论，所有代码为教学示例，不构成任何投资建议。文中不包含对任何策略有效性的评价，也不对未来收益做任何暗示。投资者据此操作，风险自担。

通过 TickDB API 获取实时行情数据

一个 API 接入外汇、加密货币、美股、港股、A股、贵金属和全球指数的实时行情。支持 WebSocket 低延迟推送，免费开始使用。