启动性能优化设计文档：数据自愈并行化 + 预过滤 一、问题现象 每次启动时，日志中出现大量类似以下输出，耗时数分钟才能完成启动： 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 - 加载历史数据失败 - 数据库错误: 数据自愈超时
数据自愈启动缓慢与修复无效：根因与修复方案 现象（来自日志） * 每次启动都对多个交易对（如 EIGEN、MOVE、FARTCOIN 等）做数据自愈。 * 部分对子始终显示「数量不足(2/3)」，连续 3 轮修复，每轮都「Level 1修复完成: 成功=1, 实际写入 1 条记录」。 * 3 轮后仍为「自愈结果: degraded | D级 (66.7%) | 数据量: 2 条」——修复没有提升可见条数。 完整因果链：输入 → 状态变化 → 调用路径 → 出错点 → 根因 1. 输入（Trigger） 项目 说明 入口 实时
数据自愈超时机制失效分析 日期：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 - 加载历史数据失败 - 数据库错误: 数据自愈超时
订单跟踪系统 — 复杂度审计报告 审计范围：src/trading/executor.py · src/trading/websocket_order_manager.py 验证方式：静态分析 + 测试网实测（scripts/verify_order_tracking.py --coin ICP --size 10） 一、审计结论 发现 5 项复杂度问题，根源均为对 Hyperliquid API 响应结构的错误假设。 测试网验证推翻了两个核心前提： 假设 实测结果 query_order_by_oid 返回 avgPx / totalSz 从不返回，两字段对任意状态均缺失 userFills 比 orderUpdates 晚到
订单追踪系统 Bug 修复设计文档 背景 对两份 Bug 报告进行代码核实后，确认以下情况： 报告误判（不需要修） * B1 双 EventBus：EventBus 是单例（__new__ + 双重检查锁），EventBus() 永远返回同一实例，不存在隔离问题 * B3 Grace Timer 竞态：_resolve 在 lock 内执行 pop(oid)，第二次调用时 identity check 失败直接 return，天然幂等 * B8 TOCTOU：_check_order_after_cancel 函数不存在，_close_limit_leg_timeout 降级路径已有 fill_px
订单跟踪系统严重 Bug 因果链分析报告 分析日期：2026-02-23 项目路径：Trading-in-websocket 分析范围：订单跟踪系统（WebSocket 事件、并发控制、数据一致性） 因果链格式：输入 → 状态变化 → 调用路径 → 出错点 → 根因 概览 发现 5 个 CRITICAL/P0 级 + 3 个 HIGH 级 Bug，分布于 EventBus 隔离、死锁、竞态、数据错误等方面。 严重等级汇总 Bug # 标题 严重等级 核心后果 B1 双 EventBus 隔离 P0 / 静默失效 WS 所有订单/