版本号需要表达变更的破坏程度
别名: 破坏程度信号 · 语义化版本 · semver · breaking change signal
概念解释
版本号不是发版计数器，而是写给使用方的破坏程度信号（version as breakage signal）。主版本上涨表示调用点必须改代码才能继续编译或保持原行为；次版本上涨表示只增加、旧调用仍合法；补丁上涨表示修理内部，公开契约未动。使用方靠这个三位数字决定「要不要打开这次更新」。数字说了「没破坏」而接口已经改名，信号就在撒谎，所有下游的依赖策略都会按谎言来。
破坏指的是公开契约：属性名、默认值、插槽位置、键盘约定、可观察的 DOM 角色。内部重构、换渲染实现、修看不见的缺陷，只要契约不变，就不配占用主版本。反过来说，只改了一行默认值但旧调用的画面翻了，那一行就是破坏，该涨主版本。
机制
包管理器和锁定文件按位数决策：自动接受补丁、审慎接受次版本、主版本要人手点头。这个自动化把版本号变成了契约的压缩编码。编码一旦与真实破坏错位，自动更新会把破坏带进生产，或反过来把安全修补挡在门外（因为有人习惯把所有改动都标成主版本，使用方再也不敢跟）。
信号要成立，发布者必须先有一份「什么算公开契约」的清单，每次改动对清单做一次分类，再选位数。没有清单，分类变成感觉：觉得改动大就涨主版本，觉得只是样式就涨补丁。感觉与调用点是否需要改代码无关，于是数字失去预测力。使用方看到的不是你的辛苦程度，而是他们的编译器会不会红。
边界
尚未承诺稳定的 0.x 阶段，主版本信号可以按约定全部视为不稳定；但一旦对外说「可以锁 1.x」，规则立刻生效。平台商店或宿主只允许一个安装版本的环境里，位数仍然要诚实，只是使用方没有「停在旧主版本」的选项——诚实变成了发布说明里的警告，而不是可选依赖。纯视觉微调若被辅助技术或截图测试当成契约（对比度、可点区域），也会变成破坏，不能因为「只是颜色」就标补丁。把日期或营销代号写进版本号，会盖掉破坏信号，应另开发布名称，不要占用这三位。
怎么落地
- 维护一份公开契约清单（属性、默认值、插槽、键盘、角色）。每次变更在清单上标记：破坏 / 增加 / 内部。位数由标记决定，不由「感觉大不大」决定。
- 在发布记录第一行写清位数理由；理由对不上标记的，不允许打标签。
- 用自动化对照上一次标签的公开 API 快照，检出未声明的破坏；检出却标成补丁的，阻断发布。
- 验证：挑三次历史发版，列出使用方必须改动的调用，对照当时的版本位数。必须改动却只涨了补丁或次版本的，记为信号撒谎。再做一个只改内部实现的提交：若检测器要求涨主版本，契约清单过宽。请一位未参与发版的使用方只看版本号，问「这次能不能自动跟」——回答与真实破坏不一致，信号就没用。