GitHub 评审怎么走
GitHub 的评审围绕 PR 展开：在 Files changed 里逐文件看改动、按行留评论或建议、最后一次性提交评审结论（评论、批准或请求修改）。掌握批量提交与建议块这两个功能，能显著减少通知噪声并缩短作者的修改时间。
基本信息
| 入口 | PR 的 Files changed 页面，可按文件标记已读 |
|---|---|
| 评论方式 | 按行评论、留建议块、整体评论 |
| 提交方式 | 攒完评论一次性提交并选择结论，避免逐条提交造成通知刷屏 |
| 评审人 | 可指定个人或团队，CODEOWNERS 会自动请求相关 owner |
行内建议（suggestion 语法）
行内建议（suggestion 语法）
```suggestion
const retries = 3;
```
# 作者可以一键应用这条建议
# 注意：建议改动若有语义变化，需在正文里说明原因实操要点
- 建议块可让作者一键应用修改，适合确定的小改动。
- 用批量模式：先加完评论，再一次性提交评审结论，避免通知刷屏。
- 评审请求可指定个人或团队，团队请求会让当前有空的人接手。
- 大 PR 先看文件清单与规模，再挑行为变化最大与风险最高的文件细读。
- 看完一部分可以先留下评论，不必等全部看完才开口。
- 把结论与理由写在评审总结里：作者与后来人都能看到整体判断，而不只是零散的行内评论。
功能与使用场景
| 功能 | 什么时候用 |
|---|---|
| 按行评论 | 指出具体位置的问题，便于作者定位 |
| 建议块 | 确定的小修改，让作者一键应用 |
| 标记已读 | 大 PR 里跟踪进度，避免重复阅读 |
| 请求修改 | 存在必须修复的问题时使用 |
在平台上直接编辑作者的分支有争议：小修可接受，涉及逻辑的改动仍应回到作者手里处理。
作者推送新提交后，已看过的文件状态可能失效：重要改动建议重新过一遍，不要只看通知里的增量说明。
行内评论适合指出具体位置的问题，方案级讨论放在整体评论里，避免关键判断被埋在代码行之间。