评审意见为什么要分级
同一份评审里，意见的份量并不相同：有的只是命名或措辞上的偏好，有的却会让线上出错。用统一前缀把两者分开，作者就能立刻知道哪条必须改、哪条可以参考。这套做法在 GitHub、GitLab 等平台上通用，靠的是团队约定，而不是工具特性。
基本信息
| nit | 风格或偏好建议，可改可不改 |
|---|---|
| 阻塞项 | 必须修改：正确性、安全、数据兼容问题 |
| 建议格式 | 前缀标签 + 理由 + 可行改法 |
| 常用标签 | nit / blocking / question / suggestion |
| 作用范围 | 任意代码评审平台（GitHub、GitLab 等） |
典型使用场景
- 代码整体可用但存在命名、格式细节时，用 nit 一次性说明，不阻塞合并
- 发现空指针、越界、缺少错误处理等真实缺陷时明确标为阻塞项
- 对实现意图不清楚时用 question 先确认，再判断是否阻塞
- 给出改进建议时附一条可直接采纳的写法，降低作者的决策成本
- 同一个 nit 反复出现时，转为文档约定或自动化检查项
评论示例
评论示例
nit: 这两处可以合并成一个 if，非阻塞
blocking: 该分支缺少错误处理，空输入会 panic，请补充
question: 这个超时值有依据吗，方便的话附上来源
suggestion: 建议用一次遍历加 map，写法更短评论前缀读法
| 前缀 | 是否阻塞 | 适用情形 |
|---|---|---|
| nit | 否 | 命名、措辞、可选的写法偏好 |
| blocking | 是 | 正确性、安全、数据兼容性问题 |
| question | 视回答而定 | 意图不清或需要补充依据 |
| suggestion | 否 | 有明确更优写法的可选改进 |
对 nit 集中批量说明，不要在大量小事上逐条阻塞合入，把精力留给高风险问题。评审的目标是提高代码质量，不是让作者按自己的偏好重写一遍。
同一个 nit 在多个 PR 里反复出现，说明它该被固化：写进代码规范文档，或用 linter、格式化工具自动检查，人工提醒会一直重复。