name: 数据自愈系统 BUG 修复
overview: 数据自愈系统存在严重配置不一致：ContinuityChecker 和 time 生成逻辑使用 5 分钟间隔（EXPECTED_INTERVAL_MINUTES=5），但实际修复和加载的是 zscore_4h 数据（4 小时=240 分钟间隔），导致连续性检查误判、生成大量虚假缺失点，进而触发无效或错误的修复。
todos: []
isProject: false
数据自愈系统严重 BUG 分析报告
完整因果链
flowchart TB
subgraph input [输入]
I1["程序启动"]
I2["heal_symbols: 有 zscore_4h 的活跃 symbol 列表"]
I3["required_count=144"]
end
subgraph state [状态变化]
S1["_load_zscore_history 加载 zscore_4h"]
S2["数据为 4h 间隔 kline_time"]
S3["ContinuityChecker 期望 5min 间隔"]
end
subgraph path [调用路径]
P1["RealtimeKlineServiceBase.__init__"]
P2["_run_data_healing"]
P3["DataHealingOrchestrator.heal_and_prepare"]
P4["_load_zscore_history → records"]
P5["checker.check_continuity"]
P6["_generate_expected_times / _generate_missing_before_records"]
P7["executor.repair"]
end
subgraph error [出错点]
E1["continuity_checker: actual_interval 240min > expected 6min"]
E2["误判每对相邻记录间有 ~47 个缺口"]
E3["生成 5min 对齐的 missing_times"]
E4["repair 用 4h K 线修补 5min 时间点"]
end
subgraph root [根因]
R1["EXPECTED_INTERVAL_MINUTES=5 硬编码"]
R2["repair_timeframe=4h 未传入连续性检查"]
end
I1 --> P1
I2 --> P2
I3 --> P3
P3 --> P4
P4 --> S1
S1 --> S2
S2 --> P5
P5 --> S3
S3 --> E1
E1 --> E2
E2 --> E3
E3 --> P6
P6 --> P7
P7 --> E4
E1 --> R1
E1 --> R2
1. 输入
2. 状态变化
- 数据来源：
_load_zscore_history 查询 zscore_4h IS NOT NULL，得到 4h 周期 zscore 记录
- kline_time 语义：来自 4h K 线收盘时间，相邻记录间隔 240 分钟
- 期望语义：config.py:10-11 中
EXPECTED_INTERVAL_MINUTES=5, TIME_TOLERANCE_MINUTES=1
3. 调用路径
RealtimeKlineServiceBase.__init__()
└─ _run_data_healing()
└─ DataHealingOrchestrator(db_client, kline_repo, symbol, base_symbol, repair_timeframe='4h')
└─ heal_and_prepare(required_count=144)
├─ _load_zscore_history(144) → 返回 4h 间隔 records
├─ checker.check_continuity() → 使用 EXPECTED_INTERVAL=5min
├─ _generate_expected_times() → 使用 5min 间隔生成时间（无数据时）
├─ _generate_missing_before_records() → 使用 5min 间隔扩展（数据不足时）
└─ executor.repair(missing_times) → 用 4h K 线修复
4. 出错点
# actual_interval = 240 min (4h 自然间隔)
# expected_interval + tolerance = 5 + 1 = 6 min
if actual_interval > self.expected_interval + self.tolerance: # 240 > 6 → True!
# 误判存在缺口，生成 47 个“缺失”时间点（每对相邻 4h 记录之间）
current = gap_start
while current < gap_end:
missing_times.append(current)
current += self.expected_interval # 5min 步长
- 144 条 4h 记录 → 相邻对 143 个 → 约
47 × 143 ≈ 6721 个虚假 missing_times
- 这些时间点为 5 分钟对齐，与 4h 周期不一致
_generate_expected_times：无历史数据时用 EXPECTED_INTERVAL_MINUTES（5min）生成 144 个时间点_generate_missing_before_records：数据不足时用 5min 步长向前扩展
对 4h 数据：
- 正确应为：
now - i * 240min，得到 4h 对齐时间
- 实际为：
now - i * 5min，得到 5min 对齐时间
repair 使用 timeframe='4h' 拉 4h K 线并计算 zscore- 5min 对齐的 missing_times 大多不对应 4h K 线收盘时间
- 结果：大量冗余或错误的修复，以及无效的迭代
5. 根因
| 根因 |
说明 |
| 间隔配置错误 |
EXPECTED_INTERVAL_MINUTES=5 在 data_healing/config.py:10 中写死 |
| 未传递 repair_timeframe |
orchestrator.py 的 repair_timeframe='4h' 未传入 ContinuityChecker、_generate_expected_times、_generate_missing_before_records |
| 设计假定 5m 数据 |
test_basic.py 使用 5min 间隔构造测试数据，与实际 4h zscore 场景不一致 |
6. 修复方案
6.1 核心修改：按 repair_timeframe 使用正确间隔
- ContinuityChecker：增加
expected_interval_minutes 参数，由 orchestrator 根据 repair_timeframe 传入（4h→240，1h→60）
- orchestrator：在
_generate_expected_times、_generate_missing_before_records 中，使用 repair_timeframe 对应的分钟数（如 _interval_minutes(repair_timeframe)）替代硬编码 5
- config.py：保留 5 作为兼容或默认值，但不再在 4h 流程中单独使用
6.2 时间范围调整（可选优化）
- orchestrator.py:374 中
time_ranges = [12, 24, 48] 为 12/24/48 小时
- 144 条 4h 数据需 24 天 ≈ 576 小时
- 建议：当
repair_timeframe='4h' 时，使用 [576, 720, 864] 等以“天”为单位的时间范围
6.3 测试修正
7. 涉及文件