建议修改块是什么
GitHub 的评论支持「建议修改」：用语言标记写成 suggestion 的代码块给出可直接采纳的替换内容，作者在页面上点击提交即可应用，省去手工复制、对齐格式与再检查一遍的麻烦。
基本信息
| 语法 | 评论代码块的语言标记位置写 suggestion |
|---|---|
| 应用方式 | 单条用 Commit suggestion，多条可先加入批量再一次性提交 |
| 适用范围 | 可对单行或选中的多行代码提出替换建议 |
| 权限要求 | 有写权限者或作者本人可采纳，无写权限者仍可提出建议 |
| 平台差异 | GitLab 也提供类似的行内建议功能，写法与入口不同 |
典型使用场景
- 评审时发现拼写错误或命名不规范，直接给出替换内容
- 统一代码风格，减少「请改成这样」的反复沟通
- 对文档措辞给出具体改法，避免理解偏差
- 批量修正同一类小问题，一次提交搞定
- 把口头建议变成可一键采纳的动作，降低采纳门槛
写法与应用
写法与应用
# 在评论中输入代码块，语言标记写 suggestion
```suggestion
return fmt.Errorf('invalid page: %d', page)
```
# 多条建议先加入批量，再一次性提交
Add suggestion to batch → Commit suggestions
# 采纳后分支上会新增提交，可在平台上直接查看该提交的改动使用要点
| 要点 | 说明 |
|---|---|
| 位置准确 | 建议块要紧贴被替换的行，上下文错位会改到别处 |
| 内容完整 | 块内写替换后的完整内容，而不是差异标记 |
| 生成文件 | 对锁文件与构建产物提建议会被下次生成覆盖 |
| 评审记录 | 建议被采纳后仍保留在评审记录里，便于回溯 |
建议修改适合明确的小改动；涉及设计取舍的问题仍应写清理由，否则评审容易变成替对方写代码，隐患不会在讨论中暴露。
采纳建议会在分支上新增提交：评审期间提交数量会增加，若团队采用压缩合并，主干历史不会因此变得零碎。