gh pr view 140 --json body --jq '.body' grep -n 'getAddress()' src/main/java/**/OrderService.java
一个 60 行的 PR 收到 12 条评审意见，11 条在说空格和命名，唯一一条逻辑问题是「这里可以简化」。上线后取地址 city 的链式调用抛 NPE，影响 300 多个订单。先别急着动参数，把报错原文和时间点记下来，顺序反了容易白折腾。
原因不复杂，评审没有检查清单，看到什么说什么，格式最显眼就先说格式。空值分支这类问题需要顺着调用链看，成本高容易被跳过。
「评审只看格式」确认了原因之后，改动尽量只碰那一处，顺手改的东西后面最容易出问题。备份不是备了就行，恢复一次才算数，很多备份文件打开才发现是空的。
接口问题先分清是没发出去、发出去了没收到，还是收到了处理失败。
处理上按这个顺序：评审前列出必查项 空值 边界 并发 事务 回滚；格式问题交给工具 评审只留逻辑意见；要求作者在描述里写清异常路径怎么处理；高风险改动安排第二个人专门看逻辑。
改完只确认一件事：评审意见里至少有一条涉及异常或边界，格式类意见占比降到 20% 以下。