什么是Code Review
这个“Code Review”本质上是一套系统化的代码审查模式，不是单一语言或框架下的技巧清单，而是把开发团队在审 PR 时最容易遗漏、最容易分散注意力的内容，重新整理成一套可重复执行的检查框架。它把审查拆成安全、性能、正确性、可维护性、测试、可访问性和文档等多个维度，强调不要凭感觉随机浏览，而要按维度逐项推进。这样做的价值在于，审查不再只围绕代码风格或个人偏好打转，而是回到真正影响线上质量的部分，比如漏洞、逻辑错误、边界条件、回归风险和长期维护成本。
从内容结构看，这套模式并不只告诉你“该看什么”，还明确了“该怎么审”。它把一次评审划分为三轮：先用几分钟看整体结构、改动范围和方案是否合理，再逐文件逐行检查细节，最后专门回头思考生产环境中的失败场景、并发问题、边界值以及缺失测试。这种分阶段方法很适合现实中的 PR 审查，因为绝大多数问题并不会在第一次浏览时全部浮现，尤其是安全与正确性问题，往往需要在理解整体意图之后再落到具体实现上。
另一个很实用的部分，是它把审查意见标准化了。每条评论都要求带上严重等级，例如会阻塞合并的 Critical 和 Major，或者更偏向改进建议的 Minor、Nitpick。配合“指出具体位置、说明风险、给出修复方向、区分主观建议与阻塞问题”的反馈原则，团队可以更清楚地知道什么必须改、什么可以后续优化，也能减少评审过程中的误解和情绪摩擦。对于想建立团队审查标准的人来说，这比单纯罗列若干检查项更接近可落地的工作方法。
核心功能特点
- 按安全、性能、正确性、可维护性、测试等维度组织审查内容，避免遗漏关键风险点
- 采用“三轮审查”流程：先看整体方案，再查逐行细节，最后补做边界与生产风险检查
- 内置大量具体检查项，覆盖 SQL 注入、XSS、N+1 查询、竞态条件、回归测试等常见问题
- 要求每条评审意见标注严重等级，明确哪些问题会阻塞合并，减少沟通歧义
- 提供结构化反馈原则与示例，强调说明原因、指出影响并尽量给出可执行的修改建议
- 专门列出橡皮图章式审批、纠结命名细节、情绪化评论等审查反模式，帮助团队提升评审质量
适用场景
它最直接的使用场景就是日常 PR 审查。无论是功能开发、缺陷修复还是重构提交，评审者都可以把这套清单当作稳定的参考框架来使用：先确认改动范围是否合理，方案有没有偏离现有架构，再检查每个 I/O 边界的错误处理、用户输入验证、数据库访问方式和测试覆盖情况。对于代码量较大、业务逻辑复杂的改动，这种分维度审查尤其有效，因为它能帮助评审者在有限时间里优先抓住真正高风险的问题，而不是把精力消耗在表层格式或个人写法偏好上。
第二类典型场景，是团队希望建立统一的代码审查标准。很多团队并非不重视 review，而是每个人关注点不同：有人只看可读性，有人盯性能，有人只会在出过事故的领域格外谨慎，结果就是审查质量高度依赖个人经验。这套模式把安全、性能、正确性、测试等维度固化下来，又补充了严重等级和反馈写法，适合作为团队内部 review 约定的基础文本。新成员加入后，也能较快理解团队认为什么是阻塞问题、什么属于优化建议、什么行为会损害审查效率与协作氛围。
它也适合用于提升个人评审能力，尤其是从开发者转向承担更多把关职责的人。很多工程师写代码经验丰富，但做 review 时容易出现“看着没问题就过”“提了意见但说不清风险”“发现问题却没法判断是否阻塞合并”等情况。借助这套模式，可以把经验判断拆解成更可训练的动作：先看架构匹配，再核对高优先级风险，最后补足边界和回滚安全；同时在表达上把“这不对”改成“这里的具体风险是什么、为什么重要、建议如何调整”。对于想把代码审查从个人习惯升级为团队质量机制的组织来说，这类结构化方法也更容易复制和持续执行。