评审结论的三种状态
主流平台把评审结论分成三种：仅评论、批准、要求修改。前两者通常不阻塞合并（具体取决于仓库规则），要求修改则会把合并暂时挡住，直到作者改动后重新获得批准。理解这三种状态，是看懂合并按钮为什么点不动的前提。
怎么用才不会互相拖时间
把阻塞状态留给真问题：会导致线上故障、破坏接口契约、缺少必要测试的改动才用「要求修改」，命名与注释这类小问题用普通评论就够。要求修改时最好给出可执行的改法，作者改完再请求重新评审，这样一轮就能收敛，比来回追问高效得多。
基本信息
| 适用平台 | GitHub、GitLab 等托管平台，名称略有差异 |
|---|---|
| 仅评论 | 提交评论，通常不阻塞合并 |
| 批准 | 明确同意合入 |
| 要求修改 | 阻塞合并，直到重新提交或撤除 |
| 命令行工具 | gh 可以提交评审结论 |
| 解除方式 | 作者改动后请求重新评审 |
典型使用场景
- 通过改动：确认没问题，给出批准让合并继续
- 提出问题：发现需要改的地方，要求修改并写清期望
- 补充意见：小建议用普通评论，不阻塞流程
- 复评审：改动完成后重新确认并批准
- 批量处理：用命令行工具对多个合并请求集中提交结论
常用示例
常用示例
gh pr review --approve # 批准合并
gh pr review 128 --request-changes --body '需要补充边界测试' # 要求修改
gh pr review --comment --body '命名建议见行内评论' # 仅评论
git fetch origin pull/128/head:pr-128 # 取出待评审分支
gh pr view 128 # 查看评审历史与阻塞状态三种状态对照
| 状态 | 是否阻塞合并 | 适用情形 |
|---|---|---|
| 仅评论 | 一般不阻塞 | 小建议、提问、补充说明 |
| 批准 | 不阻塞 | 确认改动可以合入 |
| 要求修改 | 阻塞 | 存在必须解决的问题 |
| 待重新评审 | 阻塞未解除 | 作者改动后等待再次确认 |
请求修改时给出可执行的改法，比笼统的「再改改」省下一轮往返；小问题用普通评论，不要占据阻塞状态。
部分仓库允许作者自行批准，也可能被管理员绕过。因此评审结论只是流程的一环，不能当成唯一的质量闸门。