变更日志是什么
变更日志按时间记录系统或产品的显著变化：新增、修改、修复与废弃，用用户能理解的影响描述，并标注日期与版本。它面向使用者与依赖方，因此比代码提交历史更适合对外沟通——提交记录讲实现，变更日志讲影响。
怎么维护
随发布同步更新，不要等到审计或投诉时才补记；历史条目不可篡改，修正要新增条目说明。破坏性变更与弃用项尤其重要：写清影响对象、迁移建议与停用时间，让下游有时间调整，这是最能减少升级事故的一类记录。
基本信息
| 结构 | 版本或日期 + 分组（新增、变更、修复、废弃） |
|---|---|
| 读者 | 使用方与依赖方，写影响而非实现细节 |
| 维护方式 | 随发布更新，历史条目不可篡改 |
| 重点内容 | 破坏性变更、弃用说明与迁移建议 |
典型使用场景
- 产品发布：对外说明新功能与行为变化
- API 迭代：标注字段变更与下限调整
- 平台升级：告知运维相关配置与依赖变化
- 安全修复：说明影响范围与建议动作
- 库与组件：提示破坏性变更与迁移方式
- 内部系统：让依赖团队提前准备适配
条目示例
条目示例
2026-10-12 平台 v3.2
新增：支持按服务配置告警静默
变更：API 分页默认上限调整为 200（影响导入脚本）
修复：修复导出文件名乱码问题
废弃：v2 回调地址将于 2027-01 停止支持，请改用新地址
# 影响类变更要写明受影响对象与建议动作类别与关注点
| 类别 | 写什么 | 读者关注点 |
|---|---|---|
| 新增 | 能力与适用范围 | 能否解决我的问题 |
| 变更 | 行为差异与影响对象 | 是否需要改代码或配置 |
| 修复 | 修复的缺陷与版本 | 是否需升级以规避问题 |
| 废弃 | 停用时间与替代方案 | 迁移工作量与截止时间 |
变更日志要给依赖方留出缓冲期：破坏性变更提前若干版本预告，并在临近停用时再次提醒，比上线当天公告有效得多。