批量评审是什么
批量评审指的是「待提交评论」机制：评审人先在 diff 里逐处写行内评论，这些评论处于未提交状态（仅自己可见），看完全部文件后一次性提交，并附上总结与最终结论。这样作者收到的是完整的一轮意见，而不是评审进行中被零散通知反复打断。提交前还可以随时修改或删除自己的行内评论，相当于给自己留了草稿期。
基本信息
| GitHub | Start a review → 逐处 Add review comment → Finish your review |
|---|---|
| GitLab | 行内评论可选 Start a review 攒成一轮，或 Add comment now 立即发 |
| 好处 | 作者一次性拿到整轮意见，减少往复与漏读 |
| 局限 | 未提交的评论协作者看不见，紧急阻断问题要先行单独沟通 |
| 适用 | 大 PR、需要正式结论的评审 |
典型使用场景
- 大型 PR 逐文件细读：全部看完再下结论，避免边看边发导致前后意见矛盾。
- 正式评审流程：需要 Approve / Request changes 这类可审计的结论动作。
- 带新人评审：给完整一轮意见，而不是零散打断式吐槽。
- 多人并行评审：批量提交让每位评审人的意见成为一条完整记录。
- 中断恢复：评审被打断后，待提交评论仍保留在草稿里，回来可以继续。
操作要点
操作要点
1. 在 Files changed 里逐处加行内评论（处于待提交状态）
2. 全部看完后回看文件列表与 diff 统计，查漏
3. Finish your review：写总结 + 选择结论（Approve / Comment / Request changes）结论选项对照
| 结论 | 含义 | 使用时机 |
|---|---|---|
| Comment | 只留意见不表态 | 意见不足以阻塞合并 |
| Approve | 认可当前版本 | 可以进入合并 |
| Request changes | 明确要求修改 | 再评审前通常阻塞合并 |
总结里挑出「必须修改」的 2 到 3 项，其余标记 nit（小建议），作者更容易分清优先级。GitLab 的行内评论提交后仍可编辑与回复，结论动作（Approve）与评论分开记录。