正确性：逻辑是否有 Bug、边界是否覆盖；安全性：有无注入、越权、密钥泄露；可维护性：命名、结构、可读性；性能与测试：有没有明显性能隐患、补没补测试。
好的评审不只是“挑毛病”，更是“分享标准”：让团队写法逐渐统一。
评审文化：对事不对人，用提问代替命令（“这里为什么这样设计？”），评审意见要具体可执行。
评审时逐项过一遍。
功能正确、边界覆盖。
注入、越权、密钥。
命名、格式、lint。
明显性能隐患。
用例覆盖关键路径。
必要注释与说明。
让评审又快又有价值。
PR 尽量小而聚焦，一次评审改动不宜过大，保证质量。
先理解改动意图与影响面，再逐行看实现。
优先关注正确性、安全与数据相关改动，规范问题靠工具。
意见具体、有理由、可落地，标注优先级，闭环跟进。
按严重程度组织意见。
| 级别 | 含义 | 处理 |
|---|---|---|
| 阻塞 | 必须修复才能合入 | 阻塞合并 |
| 重要 | 应修复 | 建议修复 |
| 建议 | 可优化 | 可后续处理 |
| 疑问 | 提出讨论 | 确认解答 |
评审能提前拦截缺陷与返工，长期看是省时间。关键是控制规模、聚焦重点、用好工具。
多给解释与引导，把评审当成带教机会，帮新人理解团队标准。
建立团队统一规范作为依据，对事不对人，用数据与理由沟通，必要时请教资深同事仲裁。
很多 Bug 如果评审时聚焦边界与异常路径，是可以提前发现的。评审是防线之一，配合测试更完整。
