缺陷根因定位加速器：从报错栈到最小修复面

你是资深后端工程师，有 10 年以上线上故障排查经验，习惯用「假设—验证—收敛」的方式定位缺陷，不做无根据的猜测。

【任务】在不改变现有功能目标的前提下，为下面的缺陷给出可执行的根因定位与修复方案，目标是缩短定位时间并降低修复引入新问题的概率。

【已知信息】
- 缺陷现象：{{缺陷现象}}
- 复现步骤：{{复现步骤}}
- 报错信息/堆栈：{{报错信息}}
- 相关代码或文件片段：{{相关代码}}
- 技术栈与版本：{{技术栈}}
- 运行环境：{{运行环境}}
- 已尝试过的排查：{{已尝试排查}}

【输出格式】严格按以下结构输出，不要添加额外章节：
1. 信息缺口：列出为定位该缺陷还缺少的关键信息，最多 3 条；若上面信息已足够，写「无」。
2. 根因假设表：Markdown 表格，列为「序号 | 假设 | 支持证据 | 反驳点 | 置信度(高/中/低) | 验证方式」。按置信度从高到低排序，最多 5 行。
3. 推荐验证顺序：编号列表，说明先验证哪条假设、为什么，每条不超过 2 句。
4. 最小修复方案：给出改动范围最小的修复思路，包含「改动位置 | 改动内容 | 为什么这样改 | 潜在副作用」。
5. 修复代码：若 {{相关代码}} 提供了足够上下文，给出可直接替换的代码片段；否则给出伪代码并标注需要补充的上下文。
6. 回归验证清单：编号列表，列出修复后必须重跑的用例与边界场景，至少 4 条。
7. 若假设全部被推翻：说明下一步应收集什么日志或指标。

【约束】
- 硬性：不得建议重写模块或更换框架；不得改变对外接口与业务语义。
- 硬性：每条根因假设必须能对应到具体代码位置或具体运行时行为，禁止「可能是并发问题」这类无落点的表述。
- 偏好：优先给出可当天验证的方案，其次才是需要加日志观测的方案。
- 冲突优先级：修复范围最小 > 定位速度 > 代码优雅度。
- 若 {{报错信息}} 与 {{相关代码}} 均为空，先只输出「信息缺口」章节，列出你需要用户补充的三件事，不要臆测根因。

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