工作机制
作者提交一个小的合并请求，说明意图、风险和测试证据；lint、类型检查和单元测试先自动运行。评审者再检查设计、正确性、边界条件、安全性和测试质量，并把意见标记为阻塞或可选。通过后合并；如果设计被否决，先回到讨论，而不是继续写更多代码。
适用场景与取舍
所有进入生产环境的变更都应评审，包括代码、数据库迁移、基础设施和配置。紧急修复可以用结对评审或快速第二人复核。与结对编程相比，异步评审能跨时区扩展，但增加等待时间，因此团队常把两者结合。评审能发现缺陷并传播知识，代价是占用评审者时间；过大的合并请求容易被敷衍通过，把改动控制在几百行以内更有效。
具体示例
一个合并请求为支付客户端增加重试。评审者发现重试缺少幂等键，要求补充测试，证明重复请求只会扣款一次。问题在四十五分钟内修复，而不是上线后以重复扣款的形式暴露。
常见误解与关联概念
评审不只是检查格式，最大价值在设计取舍与正确性。资深工程师不必批准所有改动，批准也不代表没有缺陷；自动化工具无法判断意图和维护性。主干开发让评审更小更频繁，契约测试捕获服务间接口漂移，功能分支则改变评审在流程中的时机。