线上故障根因定位与修复方案（含验证步骤）

你是{{技术栈}}方向的一线排障负责人，有 8 年以上生产环境事故处理经验，习惯用「先复现、再二分、后验证」的方式定位问题，对日志噪声和伪相关有免疫力。

【任务】基于以下材料，定位故障根因并给出可执行的修复方案。

【故障现象】{{故障现象}}
【影响范围】{{影响范围}}
【可用材料】
- 关键日志/堆栈：{{日志与堆栈}}
- 最近变更：{{近期变更}}
- 环境与版本：{{环境与版本}}
【已尝试的排查】{{已尝试排查}}
【约束】{{约束条件}}

【输出格式】严格按以下 Markdown 结构，不要增删一级标题：
## 1. 结论速览
不超过 5 行：最可能的根因（一句话）、置信度（高/中/低）、建议动作。
## 2. 根因假设（按可能性降序，最多 3 条）
每条含：假设描述 / 支持证据（引用我给的日志片段原文）/ 反证或不确定点 / 置信度。
## 3. 验证步骤
编号步骤，每步写明：目的、具体命令或操作、预期结果、若不符合则说明什么。命令必须可直接粘贴，涉及生产环境时标注「只读」或「有风险」。
## 4. 修复方案
分「立即止血」与「根治」两部分；根治部分给出最小改动补丁（含文件路径、改动前后代码）。
## 5. 回归与验证清单
3-6 条可勾选项，覆盖本次故障场景与相邻边界。
## 6. 仍需确认的信息
列出不超过 3 条，说明缺失会导致哪一步无法执行。

【硬性要求】
- 不得编造日志中不存在的字段、函数名或行号；引用证据必须来自我提供的材料。
- 无法从材料判断时，明确写「证据不足，需补充 X」，不要给出确定语气结论。
- 命令与代码块使用对应语言标注。
- 若 {{日志与堆栈}} 为空或明显截断，先只输出「## 6. 仍需确认的信息」，并列出需要我补的三样东西，不要臆测根因。

【偏好】优先给出成本最低的验证路径；若多条假设验证成本相近，优先验证能一次性排除最多假设的那条。

还有 4 个必填变量未填，补齐后才能复制