"开仓信号详细告警" 模块 Bug 审查报告

审查范围

审查结论

未发现严重 BUG（P0 级）。 整体代码质量较好，三级降级和异常保护设计合理，核心流程不会因为告警问题导致交易中断或资金风险。以下列出所有发现的问题，按严重程度排序。

发现的问题（按严重程度排序）

🟡 P2: _section_correlation 无法匹配序列化后的数据

文件: signal_alert_formatter.py L257-L274

问题: _section_correlation 直接用 if period_key in details 和 details[period_key] 来查找数据，但 period_key 是 tuple 类型（如 ("5m", "7d")）。当 multi_period_result 经过 JSON 序列化/反序列化后，tuple key 会变成字符串 "('5m', '7d')"，导致永远匹配不到，最终输出 "无数据"。

而同文件的 _section_health_monitor 和 _section_window_comparison 使用了 _get_period_data() 辅助函数来兼容两种 key 格式。

 def _section_correlation(mpr: dict) -> str:
     details = mpr.get("details", {})
     rows: list[str] = []

     for period_key, window_label in _WINDOW_LABELS.items():
-        if period_key in details:
-            corr = details[period_key].get("correlation", 0)
+        pd = _get_period_data(details, period_key)
+        if pd:
+            corr = pd.get("correlation", 0)
             rows.append(f"| {period_key[0]} | {corr:.3f} | {window_label} |")

影响: 如果 multi_period_result 来自 JSON 反序列化路径，相关性分析区块会永远显示 "无数据"。但在当前代码中 multi_period_result 是内存中直接传递的 dict，不经过 JSON 序列化，所以实际影响有限。这是一个一致性缺陷，未来如果数据来源变化可能会暴露。

🟡 P2: _section_cointegration 也有同样的 key 不兼容风险

文件: signal_alert_formatter.py L277-L307

问题: _section_cointegration 直接遍历 details.items()，然后通过 period_key[0] 提取 period label。如果 key 是 tuple ("4h", "60d")，则 period_key[0] = "4h" ✅。但如果 key 是字符串 "('4h', '60d')"，则 period_key[0] = "(" ❌，导致周期标签显示为一个括号字符。

影响: 同上，当前实际影响有限，但是一个潜在的显示异常。

🟢 P3: AlertSender 去重窗口过期清理存在惰性清理漏洞

文件: alert_sender.py L84-L93

问题: _is_duplicate 方法的过期清理仅在 len(self._recent_hashes) > 100 时触发。当哈希表条目 < 100 时，过期条目不会被清理。这意味着如果有一条告警在 >60 秒前发送，而在来了另一条完全相同的告警时，虽然逻辑上 content_hash in self._recent_hashes 为 True，但代码在 return 时也检查了 now - self._recent_hashes[content_hash] < self._dedup_window，所以实际上不会误去重。

return content_hash in self._recent_hashes and now - self._recent_hashes[content_hash] < self._dedup_window

结论: 虽然过期条目会在内存中积累（轻微内存泄漏），但不会导致功能性错误（不会误去重也不会漏去重）。在交易系统低频告警场景下影响可忽略。

🟢 P3: _format_full 超长截断逻辑可能 IndexError

文件: signal_alert_formatter.py L184-L188

问题: 超长截断时 core = [sections[1], sections[7], sections[8], sections[9]]，假定 sections 有至少 10 个元素。虽然有 if len(sections) >= 10 else sections[:4] 的保护，但如果某些区块的 builder 返回 None 或空字符串（if section: 过滤），sections 长度可能 < 10，此时会走 sections[:4] 分支，截断的"核心区块"并非预期的信号概览 + 风险评估 + 执行信息。

影响: 实际不太可能触发（25000 字符限制很宽松），且即使触发也只是展示内容不完美，不影响交易流程。

🟢 P3: _section_zscore_validation 符号一致性判断逻辑与 risk_evaluator 不完全一致

文件: signal_alert_formatter.py L236-L246 vs risk_evaluator.py L224-L225

问题: 两处都计算 Z-score 符号一致性，但 formatter 中的 majority_sign 是一个整数（正/负票数之差），用 (majority_sign > 0 and z > 0) 判断一致性。而 risk_evaluator 中用 abs(sum(signs)) / len(signs) 计算比例。两者逻辑略有差异，但结论一致。这不是 bug，只是一致性风格问题。

🟢 P3: 风险评估默认降级值的置信度可能误导

文件: risk_evaluator.py L87-L95

问题: 异常时返回 confidence=0.3，但该值并没有在下游被用于任何决策（仅显示在告警中）。不是功能 bug。

设计亮点（做得好的地方）

1. 三级降级 FULL → SIMPLIFIED → BASIC — 每级的 try/except 独立，单区块失败不拖垮整体
2. 最终兜底 — format_signal_alert 在 BASIC 也失败时有硬编码 fallback；_send_entry_alert 在外层也有到简短通知的降级
3. 告警与交易流程解耦 — 告警失败不影响 on_entry_signal 的返回值和仓位记录
4. 限流和去重 — AlertSender 防止消息刷屏
5. 每个区块独立 try/except — _format_full 中 10 个区块各自独立，单区块异常只产生 "⚠️ 数据缺失" 占位符

总结

整体评价: 该模块设计稳健，防御性编程到位，不存在严重 BUG。两个 P2 问题建议按优先级修复以防止未来数据来源变化时暴露。