代码审查流于形式是很多团队的通病，分享一些让 review 更有效的实践。\n\n改进方法：\n\n1. 每次审查控制在 400 行以内，超过就分批提交。研究表明审查准确度会随代码量增加而显著下降，400 行是行业经验值，PR 作者也需要主动控制粒度。\n\n2. 关注可维护性和设计，不只是找 bug。命名是否清晰、抽象是否合理、错误处理是否完善、是否有过度设计，这些比语法错误更重要，但容易被 reviewer 忽略。\n\n3. 准备审查清单，覆盖安全、性能、可读性等维度。SQL 注入、XSS、N+1 查询、内存泄漏、并发安全等常见问题用清单逐项排查，避免依赖 reviewer 的"心情"决定审查深度。\n\n4. 区分建议性问题与必须修改项，避免审查变成争论。用前缀如 nit:、optional:、blocking: 明确标注意见类型，让作者知道哪些必须处理、哪些可以讨论。\n\n你们的 code review 流程是怎样的？怎么让 review 既不流于形式又不变成吵架？