076、Bug 修复全流程：报告理解到复现到定位到修改到验证的五步工程法
从一次凌晨告警说起
凌晨2点17分，手机震动把我从梦里拽出来。PagerDuty告警：生产环境支付回调接口超时率飙升到23%。我揉着眼睛打开电脑，第一件事不是看代码，而是看告警详情——这是Claude Code项目里一个支付网关的异步回调处理模块。当时我脑子里只有一个念头：别急着修，先搞清楚到底发生了什么。
这个教训是我用三年时间、踩了无数次坑才换来的。Bug修复不是“看到问题-改代码-提交”这么简单，它是一套完整的工程流程。今天我就把这套流程拆开，用真实案例讲清楚。
第一步：理解Bug报告——别让“用户说”害了你
Bug报告从来不是真相，只是线索。那天凌晨的告警信息写着“回调处理超时”，但“超时”这个词太模糊了。我打开Sentry，看到错误堆栈指向processPaymentCallback函数，但更关键的是关联的日志片段——回调请求的body里order_id字段为空。
这里踩过坑：以前我拿到Bug报告就直接去翻代码，结果发现“用户说的现象”和“实际代码行为”完全是两码事。比如有次测试说“点击保存按钮没反应”，我查了半天发现是按钮被CSS遮住了，根本不是代码逻辑问题。
所以第一步的正确姿势是：把Bug报告翻译成可验证的技术描述。对于那个支付回调Bug，我写下了这样的技术描述：
当
