数据自愈并发优化设计方案 一、现状分析 当前流程 _run_data_healing（realtime_kline_service_base.py:1807）： for (symbol, base_symbol) in heal_pairs: # ~50+ 配对，串行 DataHealingOrchestrator(...) # → RepairExecutor.__init__ │ # → KlineDataFiller.__init__ │ # → Info(MAINNET_API_URL) HTTP 握手 ~0.85s │ # ← 第 2-50 个握手完成后才被 shared_executor 覆盖，全部浪费！ _load_zscore_history()
数据自愈并发优化设计方案 一、现状分析 当前流程 _run_data_healing（realtime_kline_service_base.py:1807）： for (symbol, base_symbol) in heal_pairs: # ~50+ 配对，串行 DataHealingOrchestrator(...) # → RepairExecutor.__init__ │ # → KlineDataFiller.__init__ │ # → Info(MAINNET_API_URL) HTTP 握手 ~0.85s │ # ← 第 2-50 个握手完成后才被 shared_executor 覆盖，全部浪费！ _load_zscore_history()
数据自愈并发优化设计方案 一、现状分析 当前流程 _run_data_healing（realtime_kline_service_base.py:1807）： for (symbol, base_symbol) in heal_pairs: # ~50+ 配对，串行 DataHealingOrchestrator(...) # → RepairExecutor → KlineDataFiller │ # Info(MAINNET_API_URL) HTTP 握手 ~0.85s │ # 第 2-50 个立刻被 shared_executor 覆盖，全部浪费！ _load_zscore_history() # DB 查询 ×1（0.08-0.56s）
数据自愈模块优化设计文档 版本：v1.0 日期：2026-02-23 范围：src/utils/data_healing/ + src/services/realtime_kline_service_base.py（_run_data_healing 部分） 目录 1. 问题全景与优先级总表 2. BUG-01：加载语义与修复语义不一致 3. BUG-02/03：单条/少量记录无法生成修复目标 4. BUG-04：日志误导性 5. BUG-05：重复写入（BUG-01 副作用） 6. BUG-06：test_basic.py 与 Diagnosis 定义失同步 7.
数据自愈模块综合问题分析报告 Context 本分析旨在全面梳理 src/utils/data_healing/ 数据自愈模块存在的各类问题，结合三份参考文档（数据自愈BUG Cursor 1.md、数据自愈BUG Cursor 2.md、启动性能优化设计文档.md）及代码实地核查，形成统一的问题清单与修复优先级建议。 一、模块架构速览 DataHealingOrchestrator.heal_and_prepare() Phase 1 : _load_zscore_history() ← SQL 时间窗口加载 Phase 2–3: 诊断-修复循环（最多3轮） ├─ _diagnose() ← 三项检查（连续性/新鲜度/数量） │ ├─ ContinuityChecker.check_continuity() │ └─ _check_freshness() ├─ RepairExecutor.
启动性能优化设计文档：数据自愈并行化 + 预过滤 一、问题现象 每次启动时，日志中出现大量类似以下输出，耗时数分钟才能完成启动： KlineDataFiller 初始化完成 | 交易所: hyperliquid 数据自愈编排器初始化 | VINE/USDC:USDC vs AAVE/USDC:USDC | timeframe: 4h 数据自愈启动 | 需要 3 条 | 间隔 240min | 理论跨度: 12h 数据不足: 2 条（12h 窗口），尝试更大范围 加载历史数据: 3 条 （16h 窗口，需要 12h） ...（每对重复一次）... 自愈失败: ADA/USDC:USDC | 完整度: 33.
KlineDataFiller 与 KlineDataFillerLazy 说明 本文档说明 kline_data_filler.py 与 kline_data_filler_lazy.py 两个模块的差异、在项目中的调用方式，以及为何通用服务与 HYPE 服务使用不同的类。 一、模块关系与技术差异 1.1 角色关系 * kline_data_filler.py：基类 KlineDataFiller，实现完整的 K 线校验与补充逻辑（连续性校验、窗口长度校验、冷却、拉取并写入等）。 * kline_data_filler_lazy.py：子类 KlineDataFillerLazy，继承 KlineDataFiller，仅改变「何时、如何创建
代码质量审计报告 日期：2026-02-23 审计范围：src/services/、src/trading/、src/utils/、src/scripts/、src/config.py 一、死代码 1.1 _safe_float() / _safe_int() — services 中重复定义 * 文件：src/services/realtime_kline_service_base.py:509–547 * 问题：_safe_float() 和 _safe_int() 作为静态方法定义在 RealtimeKlineServiceBase，但 src/trading/config.py 中已有同名同功能的独立函数，形成跨模块重复定义
数据自愈模块启动期 BUG 分析报告（Cursor 2） 基于 realtime_kline_service 启动日志与代码阅读的根因归纳。 1. 「尝试更大范围」未真正扩大窗口 现象（日志） * 出现「数据不足: 1 条（24h 窗口），尝试更大范围」后，没有再出现「加载历史数据: N 条（48h/72h 窗口）」。 * 直接进入「第 1 轮检查...」，最终「无法确定修复目标」。 根因（代码） orchestrator.py 中 _load_zscore_history 的时间窗口是写死三档： needed_hours = (required_count * self.
数据自愈模块修复执行报告 日期：2026-02-23 提交范围：src/utils/data_healing/ × 2 文件 + src/services/realtime_kline_service_base.py 变更统计：+50 行 / −111 行，净减少 61 行 一、问题背景 服务启动时数据自愈运行约 19 分钟（498 对配对），HEALING_TIMEOUT_SECONDS=300 完全无效。 根本原因：signal.alarm() 触发的 TimeoutError 是 Exception 的子类（继承链：TimeoutError → OSError → Exception）。闹钟一次性触发后，
数据自愈模块冗余分析报告 日期：2026-02-23 审计范围：src/utils/data_healing/ 全部 5 个文件 + 调用方 _run_data_healing() 一、代码规模 文件 总行数 类/dataclass 方法数 orchestrator.py 557 3 / 2 16 repair_executor.py 372 1 / 0 11 quality_assessor.py 118 2 / 1 4 continuity_checker.py 99 1 / 0 2 config.
数据自愈超时机制失效分析 日期：2026-02-23 问题：HEALING_TIMEOUT_SECONDS=300 无效，服务启动时数据自愈运行 ~19 分钟（498 对配对） 一、现象 09:20:16 - 数据自愈启动 | 498 个配对 | timeout=300s 09:25:16 - app - ERROR - 数据库连接错误: 数据自愈超时 (300秒) ← 超时触发了，但... 09:25:16 - orchestrator - ERROR - 加载历史数据失败 - 数据库错误: 数据自愈超时