美股分钟K线不完整怎么办？回测前别盲补，用 Python 分清排除、重拉和待核
TickDB Research ·
你准备把美股分钟线送进回测，时间轴却断了一段。 最危险的动作，往往不是“少了一根”，而是顺手拿前后价格补一下，然后继续跑。
先别补。
先用 TickDB 的历史一分钟K线、美股交易日和交易时段，把空档分清楚：哪些不在你的检查范围里，哪些请求没拉成功，哪些还说不清原因。先把数据输入处理干净，再决定要不要进入回测。
这篇文章给你一套顺序：先定义目标时段，再检查请求状态和时间轴，最后把空档放进排除、重拉、待核三类。
一根分钟K线没出现，不只一种可能
“美股分钟数据不完整”听起来像同一件事，实际不是。
有些空档发生在你根本不准备研究的时间里；有些是请求失败，数据还没拿回来；还有些请求成功了，时间也在目标时段内，但你暂时没有足够信息解释它。
把它们都当成“缺数据”，很容易犯两个错：
- 不该补的时间，补出一根不存在的价格；
- 该继续核对的时间，直接混进研究数据。
分钟K线不连续，不等于数据源必然漏数。
TickDB在这件事里做什么
这件事不需要一个“自动补洞工具”，需要一条能复核的判断链。
TickDB 提供历史 1 分钟K线、美股交易日和交易时段数据。你可以先拿到真实的分钟时间轴，再结合交易日、交易时段和请求状态，决定一段空档该怎么处理。
代码负责做判断和落表：
请求失败
↓
重拉请求，再重新检查
请求成功 + 不在目标时段
↓
排除，不补价格
请求成功 + 位于目标时段 + 仍缺记录
↓
待核，保留 unknown，不自动填价
TickDB 提供数据和市场上下文；排除、重拉、待核这一步，由你的 Python 脚本完成。
先把“目标时段”写下来
常规盘、盘前、盘后不是一回事。
如果你的回测只使用常规交易时段，就不该拿盘前、盘后的空档来判断“分钟数据不完整”；如果策略本来就覆盖盘前或盘后，就应该把这部分纳入检查范围。
跑脚本前，先写清楚自己的研究范围：
- 只看常规盘；
- 常规盘加盘前；
- 常规盘加盘后；
- 或者三个时段都检查。
交易日和交易时段不是为了证明“每分钟都必须有K线”，而是为了告诉你：这段时间到底应不应该被纳入本次检查。
用 Python 跑一遍
完整运行包应包含脚本、运行说明和输出目录说明。
python3 -m pip install certifi
export TICKDB_API_KEY='你的 TickDB API Key'
python3 tickdb_us_minute_gap_diagnostic.py \
--symbol AAPL.US \
--type stock \
--interval 1m \
--market US \
--date 2026-07-23 \
--output-dir ./aapl-gap-check
运行后，重点看四类结果：
- 每个请求的 HTTP 和业务状态；
- 原始记录数、去重后的记录数、首尾 UTC 时间戳；
- 缺口处置表；
- 哪些时间被排除，哪些需要重拉，哪些仍待核。
AAPL.US 的一次真实运行
下面这次样本检查的是 AAPL.US、1m、2026-07-23 UTC。
两次历史K线请求都返回 HTTP 200、业务状态为 0，分别得到 140 行和 656 行。合并后共有 796 根唯一记录，没有重复时间戳。
第一根是 2026-07-23T08:00:00Z，最后一根是 2026-07-23T23:57:00Z。
处置结果如下：
| 结果 | 段数 | 分钟数 | 对研究输入的动作 |
|---|---|---|---|
| 排除 | 1 | 480 | 不属于本次目标检查范围，不补价格 |
| 重拉 | 0 | 0 | 本次没有失败请求需要重拉 |
| 待核 | 85 | 164 | 保留缺口标记，不自动填价 |
这 85 段待核的原因都保持为 unknown。它们不是停牌、无成交、市场事件，也不能直接被解释成某一类故障。
图：AAPL.US、1m、2026-07-23 UTC 的同次真实运行。两块K线请求均返回 HTTP 200、业务状态为 0；合并后 796 根唯一记录、无重复。
分完三类以后，数据怎么进下一步？
处置表不是为了告诉你“这里有问题”，而是为了决定这段数据能不能进入下一步。
| 结果 | 下一步 |
|---|---|
| 排除 | 不纳入本次目标时段检查，也不生成补价 |
| 重拉 | 先恢复该请求，再重新生成处置表 |
| 待核 | 保留缺口标记；严格模式下暂不进入特征和回测，或进入带缺口标记的待复核队列 |
这里没有统一阈值。有人只做常规盘，有人研究盘前，有人允许带标记的数据进入探索性研究。规则由你的研究目标决定。
但有一点不该变：在原因不清楚时，不要把空档悄悄加工成价格。
两个容易忽略的问题
第一，请求成功，不代表时间轴已经可以直接使用。
请求成功只说明这次调用拿到了响应。目标时段内仍然缺记录，就该进入待核，而不是被忽略。
第二，排除不等于删除问题。
排除只是说明这段时间不属于你本次定义的检查范围。把范围、处置结果和原始时间戳留下来，后面复盘时才知道数据为什么没有进入研究。
FAQ
1. 美股分钟K线缺口可以直接用前后价格补齐吗？
不建议默认补。先检查交易日、交易时段和请求是否完整；目标时段内但原因不明的空档，应保留为 unknown，不要自动插值。
2. 怎样区分美股分钟数据缺失和接口拉取失败？
先看 HTTP 状态、业务状态、每个分块是否完成，以及原始响应。请求失败先重拉；请求成功后，再根据你定义的目标时段决定排除还是待核。
3. 除美股历史分钟K线外，TickDB还能为数据研究提供什么？
本题用到了不同K线周期、交易日、交易时段和结构化时间字段。更广的研究里，TickDB 还可以分别用于 REST 历史查询和 WebSocket 实时推送；这不代表自动补数、自动续传或没有缺口。
最后
美股分钟数据不完整时，最该避免的不是“发现空档”，而是没弄清边界就开始补、开始算、开始下结论。
先定义你的目标时段。再用 TickDB 的历史K线、交易日和交易时段重建检查范围。最后让脚本生成排除、重拉、待核处置表。
数据能不能进入研究，不该靠感觉决定。
资料链接：TickDB 历史K线文档｜交易日文档｜交易时段文档
标签：美股分钟数据不完整、美股分钟K线缺口、美股K线断档、Python拉取美股分钟数据、TickDB