版本号里那三个数字分别管什么

一、语义化版本号的约定

格式是三段数字加点：1.4.2。

• 第一个数字是主版本。有不兼容的改动就加一，之后归零。
• 第二个数字是次版本。向后兼容地加功能。
• 第三个数字是修订号。向后兼容地修问题。

判断的核心就一句话：这次改动会不会让现有代码跑不起来。会，加主版本；不会，看是加功能还是修问题。

二、什么叫不兼容

不是"改得多"就算不兼容，是依赖这个库的人必须改代码才算。

下面这些是典型的不兼容：

• 删掉一个导出
• 改一个函数的参数个数或含义
• 改一个配置项的默认值，导致老配置行为变了
• 把返回的数据结构改了

下面这些不算不兼容：

• 内部实现换了，行为一致
• 修 bug
• 加一个新导出，加一个新配置项
• 提了性能但行为一致

三、实践中容易搞错的地方

一、把"改了很多文件"当成不兼容。 改一百个文件但 API 没变，行为一致，就不该动主版本。版本号是给使用者的信号，不是给改动人次的记录。

二、bug fix 不该动次版本。 修 bug 动修订号就够了。见过不少包把每次修 bug 都发成小版本，版本号三段两位数，看着就累。

三、本地开发阶段不用发。 0.1.0 阶段随便改，不发信号。等到 1.0.0 才是对外承诺，往后就要守规矩了。

四、"内部项目不用管"也不对。 就算只有一个前端小组在用，版本号也是唯一能让所有人知道"什么时候需要同步代码"的信号。多人协作时它的价值最高——因为总有人不同步。

四、锁文件和应用版本是两回事

前端项目里还有一层：package.json 里写 "^1.4.0"，配合 lock 文件。^ 表示接受所有 1.x 的小版本，~1.4.2 表示只接受 1.4 段内的修订。

问题就出在这。如果一个包发了 1.5.0，但同时破坏了行为（作者没守约定），你的 ^1.4.0 会自动升上去，然后你莫名其妙出 bug。所以生产项目要提交 lock 文件，CI 用 npm ci 而不是 npm install，锁死实际装的版本。

五、一个实用的自查

发版前问自己一句：如果有人拿着旧版本的代码来对接我这一版，他需要改吗？

需要，改主版本。不需要但需要加东西，次版本。什么都不需要，修订号。