📄 本页由源文件
rules/按需-更新日志编写规范.mdc自动投影生成（单一权威源）。请勿直接编辑本页。
按需-更新日志编写规范
触发时机：撰写或修订项目
changelog.md（或同类版本更新说明）时。 核心：日志面向使用者，只回答「哪个组件、发生了什么、我要不要动代码」。
1. 描述方式：概括式
- 一条一句话，只写「改了什么 + 影响」；根因、算法、实现手段不写进日志
- ❌
定位尺寸改用 offsetWidth / offsetHeight，因为 transform 会让 getBoundingClientRect 返回缩放后的视觉尺寸 - ✅
修复缩放动画期间位置错位 - 根因、取舍与实现细节归 commit message / PR 描述
2. 合并同源条目
- 同一组件、同一工具函数族的多个改动 → 合并为一条
- ❌ Tooltip 定位一条 + Tooltip 交互一条
- ✅ Tooltip 定位与交互合并为一条
- 无信息量的兜底条目（如「组件库及文档代码优化」）不写
3. 保留必要信息（不得过度概括）
以下必须写清，压缩到看不出影响即不合格：
| 场景 | 要求 |
|---|---|
| 破坏性变更 | 保留 ⚠️ **破坏性变更** 前缀，写明「移除了什么 / 改用什么」 |
| 默认值变化 | 写明旧值 → 新值 |
| 需用户改代码 | 写明替代写法 |
4. 格式约定
- 每条以动词开头：
新增/优化/增强/修复/重构 - 组件与工具函数名用 Markdown 链接指向文档，如
[文字提示 Tooltip](/guide/components/tooltip.html) - 属性名、API、全局对象等用行内代码包裹
- 单版本条目建议 ≤ 8 条
5. 版本与历史
- 已发布版本的历史条目默认不回改，用户明确要求时才回改
- 新版本严格按本规范撰写，不因历史风格而妥协
6. 自检清单
- [ ] 每条能否一句话说清「改了什么 + 影响」？
- [ ] 同组件 / 同工具函数族的条目是否已合并？
- [ ] 破坏性变更、默认值变化是否写明替代用法？
- [ ] 是否残留根因、算法、内部函数名等实现细节？
- [ ] 无信息量的条目是否已删除？
- [ ] 单版本条目数是否 ≤ 8？