stacktrace-log-triage

堆栈跟踪日志分诊

来源映射：源自 Kotlin_Spring_Developer_Pipeline.md（SK-15）的一级关键技能。

使命

将嘈杂的故障证据转化为按可能性排序的诊断，并明确说明置信度。 始终区分症状、直接原因和真正的根本原因。

先收集证据

• 阅读完整的堆栈跟踪，而不只是最顶部的堆栈帧。
• 阅读首次故障前后的日志行。
• 尽可能记录时间戳、关联 ID、请求 ID、线程名称和活动配置文件。
• 如果有近期相关的代码或配置变更，请一并查看。
• 尽可能复用 project-context-ingestion 中的仓库约束。

分诊工作流

1. 找出最早出现的有效故障信号。
2. 沿着 Caused by: 链追溯，直到原因不再变得更具体。
3. 对事件进行分类：
   • DI 和上下文启动
   • 配置绑定
   • 序列化或验证
   • SQL 或迁移
   • HTTP 或超时
   • 安全
   • 并发或锁定
   • 类路径或版本不匹配
4. 区分发生了什么故障与故障原因。
5. 证据不完整时，按可能性对假设排序。
6. 分别提出快速缓解措施和适当的修复方案。

诊断规则

• 将 BeanCreationException、InvocationTargetException 等包装异常视为传递信息的载体，而非诊断结论。
• 将框架包装层之后的第一个用户代码堆栈帧视为高价值证据。
• 依据日志时间顺序判断，而不只看堆栈深度。
• 如果日志被截断，请明确说明，并降低置信度。
• 优先采用基于观察到的代码路径或配置的解释，而不是凭记忆进行模式匹配。

高级信号模式

• 检查被抑制的异常、堆栈跟踪上方一两行中的根因日志，以及相邻线程上的伴随故障。最有用的线索往往根本不在主堆栈中。
• 区分硬故障和饱和模式：连接池耗尽、线程池资源枯竭、事件循环阻塞、重试风暴和死锁重试，往往会先表现为次要症状。
• 对于 SQL 故障，如果有供应商代码和 SQL 状态，请检查这些信息。它们通常比包装异常类型更有助于采取行动。
• 对于版本或部署变更后的启动故障，应先比较类路径和配置的差异，再假设是代码错误。
• 对于间歇性故障，应重点考虑时间相关性和并发上下文。竞态条件很少会留下清晰的单线程叙述。
• 对于 OOM 或 GC 相关事件，普通堆栈跟踪的证据力较弱。线程转储、堆内存症状和分配上下文更重要。
• 如果有指标，应将首次错误激增与延迟、资源池饱和或下游依赖退化关联起来，而不要孤立地看待日志。
• 如果症状出现在响应式或协程代码中，请确认上下文传播是否导致日志关联信息丢失，再判断缺少 ID 或线程名称具有误导性。

专家启发式

• 分诊后的首个修复应同时降低不确定性并缓解问题。优先选择还能让诊断更清晰的缓解措施。
• 如果多个候选原因都符合，请根据证据、影响范围和拟议缓解措施的可逆性进行排序。
• 如果跟踪指向框架包装层，应先向外检查近期变更的代码和配置，再沿因果链向内追溯。
• 始终说明哪些证据能够证伪最可能的假设。

输出约定

返回以下部分：

• Root cause：用通俗语言说明已确认或最可能的原因。
• Confidence：已确认、高、中或低。
• Evidence：支持该诊断的日志行、异常、配置事实或代码路径。
• Hotfix：最安全的即时遏制或解阻步骤。
• Long-term fix：恰当的代码或配置修正。
• Reproduction and verification：如何复现、测试和监控修复效果。

安全规则

• 将假设标明为假设。
• 除非事故确实没有更安全的选择，否则不要建议将高风险的架构变更、版本升级或大范围重构作为热修复。
• 日志不完整时，不要声称结论确定无疑。
• 修复后，不要忽视告警或监控方面的影响。

Kotlin 专项检查

• 留意平台类型导致的 NullPointerException。
• 留意可能掩盖原始调用路径的协程堆栈跟踪。
• 留意缺少 Kotlin 编译器插件而导致的运行时行为缺失。
• 留意 Jackson 与 Kotlin 构造函数的问题，这类问题可能表现为通用的反序列化错误。

质量标准

一次优秀的技能运行会帮助用户从故障证据找到安全的修复方法。 一次糟糕的运行会重复最上层的异常，忽略 Caused by: 链，或在未说明风险的情况下提出危险的热修复。