git blame -L 120,140 src/main/java/**/RefundService.java git log --grep='REF-88' --oneline
线上出问题要追溯某段逻辑是谁在什么时候批准的，PR 里只有一个 approve 图标，评论在已删除的分支上，企业微信的会话记录过期无法查看。先别急着动参数，把报错原文和时间点记下来，顺序反了容易白折腾。
原因不复杂，评审结论只存在即时通讯里，代码平台没留决策记录。审批动作被简化成一个按钮，没有留下判断依据。
「评审记录追溯」排查到最后往往是很小的一处差异，前面那些复杂猜测可以先放一放。改动写完就同步给同事，下一个人踩同一个坑，成本还是你的。
验证用真实数据走一遍，测试数据太干净，边界情况根本碰不到。
处理上按这个顺序：所有评审结论回到 PR 里写 不用聊天工具定案；高风险改动要求写明影响范围和回滚方式；定期归档已合并 PR 的评审摘要；追溯时用 git blame 加 PR 编号定位决策。
改完只确认一件事：任意一行代码都能通过 blame 找到 PR 编号，PR 里能看到评审结论和回滚说明。