systematic-debugging

# 系统性调试 ## 概述 随机修复会浪费时间并产生新的 Bug。快速补丁会掩盖潜在问题。 **核心原则：** 在尝试修复之前，始终寻找根本原因。修复症状即是失败。 **违反此流程的字面要求即是违反调试的精神。** ## 铁律 没有根本原因调查，绝不进行修复 如果你没有完成阶段 1，则不能提出修复方案。 ## 何时使用 用于任何技术问题： - 测试失败 - 生产环境 Bug - 意外行为 - 性能问题 - 构建失败 - 集成问题 **特别是在以下情况使用：** - 时间压力下（紧急情况容易让人产生猜测的冲动） - “只需一个快速修复”看起来很明显时 - 你已经尝试了多次修复 - 之前的修复无效 - 你没有完全理解问题 **不要跳过的情况：** - 问题看起来很简单（简单 Bug 也有根本原因） - 你很匆忙（仓促只会导致返工） - 经理要求立即修复（系统性方法比盲目尝试更快） ## 四个阶段 你必须在进入下一阶段之前完成当前阶段。 ### 阶段 1：根本原因调查 **在尝试任何修复之前：** 1. **仔细阅读错误信息** - 不要跳过错误或警告 - 它们通常包含确切的解决方案 - 完整阅读堆栈跟踪 - 记录行号、文件路径、错误代码 2. **一致性复现** - 你能可靠地触发它吗？ - 确切步骤是什么？ - 它每次都发生吗？ - 如果无法复现 → 收集更多数据，不要猜测 3. **检查近期变更** - 有什么变化可能导致此问题？ - Git diff，最近的提交 - 新的依赖项，配置变更 - 环境差异 4. **在多组件系统中收集证据** **当系统有多个组件时（CI → 构建 → 签名，API → 服务 → 数据库）：** **在提出修复之前，添加诊断工具：** 对于每个组件边界： - 记录进入组件的数据 - 记录离开组件的数据 - 验证环境/配置的传播 - 检查每一层的状态 运行一次以收集证据，显示在哪里中断 然后分析证据以识别故障组件 然后调查该特定组件 **示例（多层系统）：** bash # 第一层：工作流 echo "=== 工作流中可用的密钥： ===" echo "IDENTITY: ${IDENTITY:+SET}${IDENTITY:-UNSET}" # 第二层：构建脚本