评审检查清单是什么
代码评审最容易失焦：注意力被格式和一个命名吸走，真正会出问题的边界条件却没人看。固定清单的作用是把评审顺序排好——先正确性与安全，再看设计与可维护性，风格细节放最后。它不追求穷尽，而是保证每次评审都覆盖高风险维度，也帮新人快速建立判断框架。适用于任何平台的 PR 与 MR，清单内容按项目风险调整。
基本信息
| 适用场景 | PR/MR 代码评审 |
|---|---|
| 使用方式 | 评审前过一遍，按维度提问 |
| 规模建议 | 控制在 5 到 7 项 |
| 配套 | review 用语区分必须修改与建议 |
| 平台 | 与托管平台无关 |
评审关注点
| 维度 | 检查问题 |
|---|---|
| 正确性 | 边界条件、错误处理、并发与时区是否覆盖 |
| 安全 | 输入校验、权限校验、日志与密钥是否脱敏 |
| 可维护性 | 命名、职责划分、重复代码、注释是否到位 |
| 测试 | 是否补充用例，断言是否验证真实行为 |
| 兼容性 | 接口与数据结构变更是否有迁移说明 |
评审节奏建议
- 先读描述与验证步骤，再看 diff，避免被代码牵着走
- 从整体结构入手，确认改动方向没问题再逐行
- 高风险代码（鉴权、支付、数据迁移）逐行读，其余可粗看
- 发现问题先问意图，确认为缺陷再给修改建议
- 评审完做一次结论：是否可以合入、还差哪几项
评审用语示例
评审用语示例
- 这里 page 为 0 时会怎样？建议补一个用例 # 提问题，指向具体边界
- 这个查询在列表页会执行多少次？是否需要批量 # 关注性能
- nit: 命名建议用 retryCount（不阻塞合入） # 标记为风格建议
- 这段并发访问需要加锁吗？ # 指出潜在风险把「必须修改」与「建议/nit」明确区分，作者才知道哪些是合入前置条件；清单过长会被跳过，按本项目的高频风险挑选条目。