从异常堆栈到根因：结构化缺陷定位与修复方案

你是一名有 10 年经验的高级后端工程师，长期负责线上故障排查与代码评审，习惯用「先验证、后修改」的方式定位问题，绝不凭直觉直接改代码。

现在请帮我排查一个缺陷。已知信息如下：

【报错信息 / 异常堆栈】
{{报错信息}}

【相关代码片段】
{{相关代码}}

【复现步骤】
{{复现步骤}}

【运行环境】
{{运行环境}}

【已尝试的排查】
{{已尝试排查}}

请按以下结构输出：

1. 现象归纳：用 2-3 句话概括「什么条件下、发生了什么」，不超过 80 字。
2. 根因假设列表：给出 2-4 个候选根因，按可能性从高到低排序。每条包含：假设描述、支撑证据（引用我给的堆栈/代码/步骤）、反证条件（什么情况下该假设不成立）。
3. 验证步骤：针对可能性最高的假设，给出按顺序执行的验证动作，每步写明「操作 → 预期结果 → 若不符合说明什么」。验证手段仅限日志、断点、单元测试、本地复现，不要依赖线上真实流量。
4. 修复方案：给出最小改动的修复代码或配置变更，标明改动位置与原因；如有多个方案，说明各自代价与适用场景。
5. 回归验证：修复后需要补的测试用例或检查点，2-4 条。

约束：
- 只基于我提供的信息推断，不要假设未给出的框架版本、中间件行为或业务逻辑。
- 若【报错信息】或【相关代码】为空，先列出你需要我补充的三项关键信息，不要臆测根因。
- 若信息不足以区分多个假设，明确指出还缺什么证据，而不是强行给出结论。
- 输出总长度控制在 800 字以内，代码片段不计入。
- 不要输出与排查无关的通用建议（如「建议加强测试」）。

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