真正高质量的 Code Review，本质是一种工程质量治理机制，而不是代码挑错行为。
本文将从专家团队视角，系统回答两个问题：
-
Code Review 应该重点检查哪些内容？
-
团队应如何进行合理、可持续的 Code Review？
一、重新理解 Code Review 的本质
Code Review 的目标并不是"让代码更优雅"，而是：
-
降低系统风险（Bug、性能、安全）
-
保障长期可维护性
-
统一团队工程标准
-
促进技术认知共享
Code Review 的本质，是用团队智慧对抗系统复杂性。
二、Code Review 应该检查什么？（核心 Checklist）
1️⃣ 正确性（Correctness）------这是底线
这是 Code Review 的第一优先级。
重点检查：
-
代码是否完整实现需求？
-
是否覆盖边界条件和异常路径？
-
是否存在明显逻辑错误？
-
异步 / 并发逻辑是否安全？
常见问题示例：
-
空值未处理（null / undefined）
-
状态未对齐（前后端不一致）
-
异步竞态条件
-
错误被 silently swallow
原则：
任何"可能导致错误结果"的问题，都是必须修改项（Must Fix）。
2️⃣ 可读性（Readability）------决定代码能活多久
代码的主要读者是未来的同事，而不是编译器。
重点检查：
-
命名是否准确表达业务含义？
-
函数是否职责单一？
-
复杂逻辑是否被合理拆分？
-
是否存在魔法数字 / 魔法字符串？
优秀代码的特征：
-
不需要额外解释也能读懂
-
注释解释「为什么这样做」，而不是「做了什么」
3️⃣ 可维护性（Maintainability）------长期成本控制
重点关注：
-
是否遵循项目既有架构？
-
是否引入重复逻辑？
-
未来需求变化是否容易扩展？
-
是否破坏模块边界？
警惕信号：
-
一个函数承担多个职责
-
组件 / 模块体积持续膨胀
-
为"临时需求"写的永久代码
4️⃣ 性能（Performance）------不要制造隐性债务
并非所有代码都需要极致优化，但明显的性能隐患必须指出。
前端常见关注点：
-
不必要的重渲染
-
大列表无虚拟化
-
重复计算、频繁创建对象
-
主线程阻塞逻辑
后端 / 通用关注点：
-
不必要的 I/O
-
N+1 查询
-
重复计算
5️⃣ 安全性（Security）------不可忽视
重点检查：
-
是否存在 XSS / 注入风险？
-
是否有敏感信息硬编码？
-
权限与鉴权是否完整？
-
用户输入是否被信任？
安全问题在 Code Review 阶段发现，成本最低。
6️⃣ 测试与可验证性（Testability）
重点检查：
-
是否有单元测试 / 集成测试？
-
测试是否覆盖核心路径？
-
代码是否易于 Mock 和测试？
原则：
没有测试的核心逻辑，本质上是"未经验证的假设"。
三、如何"合理"地进行 Code Review（方法论）
1. 小 PR 原则
-
单个 PR 建议 ≤ 300 行（不含自动生成代码）
-
一个 PR 只解决一个问题
大 PR 是 Code Review 失败的开始。
2. 先自动化，后人工
Code Review 不应该做机器能做的事。
Review 前必须通过：
-
Lint
-
单元测试
-
CI 构建
人力只聚焦：
-
业务逻辑
-
架构设计
-
风险判断
3. 明确问题级别
建议在 Review 中区分：
-
Must Fix：必须修改，否则不能合并
-
Suggestion：建议优化，可讨论
-
FYI：仅提示，不要求修改
这能极大减少无效争论。
4. Reviewer 行为规范（决定文化）
Reviewer 应该：
-
评论代码，而不是评价人
-
给出理由，而不是结论
-
以建设性建议为导向
❌ 不推荐：
这样写不太好
✅ 推荐：
这里逻辑较复杂，建议拆分函数以降低维护成本
5. Author 的责任
-
认真回应每一条 Review
-
对不同意见给出技术依据
-
不进行"防御式回应"
Code Review 是协作，不是对抗。
四、推荐的 Code Review 流程
开发完成
↓
自检（Lint / Test）
↓
提交 PR（清晰描述）
↓
Reviewer 审查
↓
讨论 / 修改
↓
Approve
↓
Merge五、常见反模式（值得警惕）
-
只看代码风格，不看逻辑
-
Review 流于形式（LGTM）
-
PR 无背景说明
-
大量线上 Bug 从未反向修正规范
六、结语：把 Code Review 当成工程能力
成熟团队的标志，不是写得多快，而是：
在复杂系统中，持续稳定地产出高质量代码。