1. 定位：先复现，再缩小范围
- 稳定复现：任何 Bug 都必须先能在本地或测试环境稳定复现。记录精确的环境版本、数据状态、操作步骤。对于偶现 Bug，先通过日志、监控或临时埋点抓住现场，避免盲目猜测。
- 隔离边界：采用“二分法”缩小范围。如果是回归 Bug，通过
git bisect或版本对比定位引入问题的提交；如果是接口异常，先用 Postman/curl 直连后端，排除前端传参干扰。 - 找到根因：区分“现象”与“根因”。页面白屏可能是空指针，也可能是后端返回了非预期结构。结合日志堆栈、断点调试和代码走读，定位到真正出错的那一行及其上下文。
2. 修复：最小改动，精准解决
- 只修根因：针对根因做最小化修改，不绕弯、不掩盖。例如并发写入异常应加锁或换原子操作，而不是简单用
try-catch吞掉异常。 - 同类排查：检查相同模式在其他模块是否存在。若某个工具类方法存在空指针风险，全局搜索调用点，一并修复。
- 避免过度重构：Bug 修复阶段不借机做大范围重构。若必须采用临时方案（hotfix），需在代码中标注
TODO/FIXME，并创建后续优化任务。
3. 验证：本地→测试→线上
- 本地验证：在本地按复现步骤确认 Bug 已解决，并跑通相关单元测试，确保无编译警告。
- Code Review：提交时说明 Bug 原因、修复思路和回归风险点，重点让 Reviewer 关注边界条件和异常分支。
- 回归测试：在测试环境验证主流程及改动关联的上下游模块，防止“修 A 坏 B”。
- 线上观察：上线后持续观察错误率、核心接口延迟等业务指标 30 分钟至 2 小时，确认无异常后再标记该 Bug 已关闭。
4. 常见误区
- 只修表象：对空指针只做判空处理，却不处理“为什么为空”，导致后续流程静默失败或数据状态错误。
- 忽视环境差异：本地无法复现就基于猜测修改，未考虑测试/线上数据差异、配置差异或并发场景。
- 漏掉数据兼容：修复逻辑仅对新数据生效，未处理历史脏数据，导致线上仍有异常触发。