PR 描述该怎么写
一份能被顺利评审的描述，通常要回答几个问题：为什么改、改了什么、怎么验证、有什么影响与风险、跟哪些单号相关。把这些写进描述，评审者不必逐个翻提交去猜意图，来回追问的次数会明显下降。多数托管平台支持描述模板，可以在仓库里放一个模板文件把它固定下来，配合具体项目补充验证命令与回滚方式。
基本信息
| 推荐结构 | 背景与目的 → 改动内容 → 验证方式 → 影响与风险 → 关联项 |
|---|---|
| 验证方式 | 列出执行的命令、测试用例、手动步骤 |
| 关联项 | 如 Closes #123、Ref !45 |
| 模板位置 | 仓库内的 PR/MR 模板文件 |
| 平台 | GitHub 与 GitLab 均支持模板 |
典型使用场景
- 任何需要他人评审的改动，尤其是涉及行为变化的
- 修复线上缺陷，需要说明复现路径与验证结果
- 配置或数据变更，需要写明影响面与回滚方式
- 跨模块改动，需要解释为什么牵动多个位置
- 大改动分阶段交付时说明本次属于哪一阶段
- 新人第一次提 PR 时按模板填写，减少沟通成本
描述示例
描述示例
## 目的
修复分页参数溢出导致的服务端 500。
## 改动
- 分页参数改为整型校验并加边界测试
## 验证
- go test ./pkg/pagination/...
- 手动验证 /api/list?page=-1
## 影响与风险
无接口字段变化，异常参数改为返回 400。
## 关联
Closes #1234各部分的检查点
| 部分 | 检查点 |
|---|---|
| 目的 | 说清动机，而不只是复述改动 |
| 验证 | 给出可复现的命令或步骤 |
| 风险 | 写清影响面与回滚方式 |
| 关联 | 补齐单号，便于自动关闭与追溯 |
描述里贴关键日志或截图时要脱敏；涉及配置变更的，写出回滚方式，评审者才能评估最坏情况下的处置成本。