- 先确认是否在争论同一个问题：目标、约束、事实前提是否一致
- 用数据与规则说话：性能数据、兼容性要求、风格指南条款
- 两轮未收敛 → 当面或语音讨论，半小时胜过三天评论
- 结论回到改动里留记录：评论或描述中说明为何这样定
评审目标是代码库健康，不是'谁赢'；僵持时可请负责人或架构师裁决。
| 收敛信号 | 双方能复述对方观点并认可其中的合理部分 |
|---|---|
| 裁决记录 | 作者综合决策后把理由写入 PR 或设计文档 |
评审分歧的处理
评审意见不一致时的处置顺序：先澄清事实与目标，再讨论方案；两轮内未收敛则转当面沟通，由作者综合意见决策并留记录。
易错点
- 在评论区打持久战：字数越来越多、共识越来越少
- 把方案分歧伪装成正确性问题：用'必须改'语气胁迫作者
数据来源与参考
- Google Engineering Practices · The Standard of Code Review（分歧与升级）