数据自愈模块启动期 BUG 分析报告（Cursor 2）

基于 realtime_kline_service 启动日志与代码阅读的根因归纳。

1. 「尝试更大范围」未真正扩大窗口

现象（日志）

• 出现「数据不足: 1 条（24h 窗口），尝试更大范围」后，没有再出现「加载历史数据: N 条（48h/72h 窗口）」。
• 直接进入「第 1 轮检查...」，最终「无法确定修复目标」。

根因（代码）

orchestrator.py 中 _load_zscore_history 的时间窗口是写死三档：

needed_hours = (required_count * self.interval_minutes) / 60
time_ranges_hours = [
    math.ceil(needed_hours),           # 12
    math.ceil(needed_hours * 1.3),     # 16
    math.ceil(needed_hours * 2),       # 24
]
time_ranges_hours = sorted(set(time_ranges_hours))  # [12, 16, 24]

对 4h、要 3 条时，最大只尝试 24h。24h 仍只有 1 条时循环结束，没有 48h/72h 等更大窗口，「尝试更大范围」只是日志文案，没有对应逻辑。

涉及文件：src/utils/data_healing/orchestrator.py（约 L417–425）。

2. 仅 1 条数据时不生成任何修复目标

现象（日志）

SEI、XAI、IOTA、CAKE、SUPER、FARTCOIN(vs BTC)、PEOPLE、ATOM 等出现：

• 「数量不足(1/3), 已过时1284min」
• 「无法确定修复目标，终止修复」

根因（代码）

• 在 _diagnose 里，shortfall_targets 只在「连续且无缺口且数量不足」时生成：

# 3. 数量不足检查
shortfall_targets: List[datetime] = []
if is_continuous and not gap_times and len(records) < required_count:
    shortfall_targets = self._generate_shortfall_targets(records, required_count)

• continuity_checker 在 少于 2 条 时直接返回 is_continuous=False：

if len(records) < 2:
    logger.debug(f"数据点不足（{len(records)}条），无法判断连续性")
    return False, [], completeness_pct

因此：当只有 1 条时，is_continuous 恒为 False，shortfall_targets 永远为空，_merge_repair_targets 得到空列表 → 打印「无法确定修复目标」。
即：恰恰在「只有 1 条、最需要补数」的场景下，自愈逻辑不生成任何补数目标。

涉及文件：src/utils/data_healing/orchestrator.py（L235–238）、src/utils/data_healing/continuity_checker.py（L55–57）。

3. 加载「时间窗」与修复「向更早补」语义不一致

（与 docs/数据自愈BUG Cursor 1.md 中的根因一致。）

• 加载：kline_time >= NOW() - N 小时，只看「最近 N 小时内」的数据。
• 数量不足时的修复：在当前最早一根之前向更早补点（_generate_shortfall_targets 里 earliest_time - i * interval）。

结果：补进去的 bar 若早于当前 12h/16h/24h 窗，重载时仍用同一套时间窗，看不到刚补的那条，出现「修了也白修」、多轮修复无效。
当前日志里多数在「只有 1 条」就终止，尚未进入多轮修复；一旦修复 1 条场景，仍会撞上「补了重载看不见」的问题。

涉及文件：src/utils/data_healing/orchestrator.py（_load_zscore_history 与 _generate_shortfall_targets）。

4. 同一标的在不同配对下表现不一致

现象（日志）

• FARTCOIN vs kNEIRO：12h 窗即拿到 3 条，自愈 ready。
• FARTCOIN vs BTC：24h 窗仍只有 1 条，自愈 failed。

说明

自愈是按 (symbol, base_symbol) 在 analysis_results 里查的，每个配对独立。有的配对历史上只写过很少的 zscore（例如只有 1 根 4h），所以即使用 24h 窗也只有 1 条。
这不是实现错误，但说明：「数据不足」往往对应该配对历史数据本身就极少；若 1 条时还不生成修复目标（见第 2 点），这些配对就会一直 failed。

5. 「已过时 1284/1285min」与单条数据

「已过时1284min」约 21.4 小时，说明那唯一一条是约一天前的 4h bar。
对 4h 来说，新鲜度阈值是 interval_minutes * FRESHNESS_MULTIPLIER（约 600 分钟），因此会被判为过时。

问题在于：过时 + 只有 1 条 时，既没有生成 shortfall_targets（因为 is_continuous=False），stale_targets 又只在 len(records) >= required_count 时生成，因此既不会按「数量不足」补更早的 bar，也不会按「过时」补更新的 bar，结果就是直接放弃。

涉及逻辑：_diagnose 中 shortfall 与 stale 的生成条件。

小结（BUG 清单）

建议修复方向（与 Cursor 1 文档一致）

1. 1 条/0 条也生成修复目标
   在 len(records) < required_count 时，即使 is_continuous=False（例如只有 1 条），也生成 shortfall_targets（从当前最早一根向前补足到 required_count），或对 0 条沿用 full_timeline。

2. 真正扩大窗口或改为「最近 N 条」

   • 要么在 _load_zscore_history 中增加更大窗口（如 48h、72h、168h）；
   • 要么改为「按 ORDER BY kline_time DESC LIMIT required_count（可加最大时间范围）」的「最近 N 条」语义（推荐，见 Cursor 1 方案 A）。

3. 修复后重载语义与「补更早」一致
   若保留时间窗，则修复后重载至少应扩大窗口以包含本次 shortfall 目标时间；或采用「最近 N 条」使补写条在重载时可见。

4. 可选：缩小启动自愈范围 / 提前终止无效轮次
   见 Cursor 1 方案 C，减少启动耗时与无效 3 轮。

涉及文件一览

• src/utils/data_healing/orchestrator.py：加载、诊断、shortfall/stale 生成、重载
• src/utils/data_healing/continuity_checker.py：len(records)<2 时返回 is_continuous=False
• src/utils/data_healing/config.py：LOAD_TIME_MARGIN 等
• 参考：docs/数据自愈BUG Cursor 1.md（完整因果链与方案 A/B/C）