变更日志怎么分组
变更日志按固定分组组织，读者才能迅速判断这次升级对自己有什么影响。通行做法是按新增能力、缺陷修复、破坏性变更分组，必要时补充性能、文档、内部改动等类目。分组名最好与提交类型一一对应，例如新功能归入新增、修复归入缺陷修复，长期稳定下来，机器生成与人工书写才会一致。
基本信息
| 推荐分组 | 破坏性变更 / 新增 / 缺陷修复 / 性能 / 其他 |
|---|---|
| 分组来源 | 由提交类型映射而来，例如新功能对应新增 |
| 破坏性变更 | 单独置顶，并给出迁移方式 |
| 版本标题 | 版本号与发布日期 |
| 稳定性 | 分组名一旦确定尽量不要频繁改动 |
典型使用场景
- 每次发版整理面向使用方的变更清单
- 把破坏性变更置顶，提醒升级方先做迁移
- 给条目附上问题编号，便于反查背景
- 自动从提交信息生成日志时，用分组规则控制归类
- 把内部重构折叠或省略，避免稀释对使用方有价值的信息
分组骨架
分组骨架
## [1.5.0] - 2026-10-12
### 破坏性变更
- 默认开启强制 HTTPS（迁移：更新回调地址）
### 新增
- 支持邮箱验证码登录（#4821）
### 缺陷修复
- 修复分页参数溢出（#4833）
### 性能
- 列表接口响应时间下降分组读法
| 分组 | 来源类型 | 写作要点 |
|---|---|---|
| 破坏性变更 | 带破坏性标记的提交 | 必写迁移方式与影响范围 |
| 新增 | 新功能类提交 | 一句话说清能做什么 |
| 缺陷修复 | 修复类提交 | 附上关联问题编号 |
| 性能与其他 | 性能与杂项提交 | 内部改动可折叠或省略 |
仓库贡献指南里应固定分组约定与条目写法，避免每次发版都重新讨论格式；格式定下来之后，自动化生成的结果也更稳定。
破坏性变更只列标题而不写迁移方式，会让升级方反复追问，这一项应当作为发布前的必检内容。