Composer包版本须遵循SemVer 2.0.0规范：X.Y.Z中X增表示不兼容变更，Y增表示兼容新功能，Z增表示兼容修复；0.Y.Z属开发阶段，不稳定；Git标签需带v前缀；^与~约束行为因版本起点而异，^1.2.3允许Y/Z升级，~1.2.3仅允许Z升级。
Composer 包的版本号应严格遵循 SemVer 2.0.0（语义化版本规范），即采用 X.Y.Z 三段式格式：主版本号.次版本号.修订号。它不是随意编号，而是通过数字变化明确传达变更性质——让开发者一眼判断升级是否安全。
主版本号、次版本号、修订号各自代表什么
每一部分递增都有明确定义：
-
主版本号（X）：发生不兼容的 API 修改时递增，例如移除方法、重命名类、改变函数签名。升级如
2.9.0 → 3.0.0意味着需人工检查并适配代码。 -
次版本号（Y）：以向后兼容方式添加新功能时递增，例如新增一个未破坏旧逻辑的接口或配置项。升级如
1.2.5 → 1.3.0通常无需修改调用方代码。 -
修订号（Z）：仅用于向后兼容的缺陷修复、安全补丁或内部优化。升级如
4.1.2 → 4.1.3可视为“安全更新”，推荐无条件接受。
特别注意：0.Y.Z 属于初始开发阶段，语义上不承诺稳定性——0.1.0 → 0.2.0 也可能含破坏性变更，生产环境应避免依赖此类版本。
Git 标签必须带 v 前缀且格式规范
Composer 本身不读取代码，而是通过 Git 仓库的标签（tag）识别正式发布版本。因此：
- 标签名必须是
v1.0.0、v2.3.4-beta.1这类带v前缀的标准格式，Composer 会自动剥离v解析为1.0.0； - 禁用非标准命名，如
release-1.0、beta2或1.0.0-final，Packagist 无法识别，用户也无法通过composer require安装； - 每次发布都应在对应 commit 上打标签并推送到远程：
git tag v1.2.0 -m "Release 1.2.0"→git push origin v1.2.0。
预发布与构建元数据的写法和用途
SemVer 允许在 X.Y.Z 后追加扩展标识，Composer 完全支持：
-
预发布版本：用短横线连接，如
1.0.0-alpha、2.1.0-rc.3。排序优先级低于正式版（1.0.0-alpha ），且 <code>alpha ； - 若要安装预发布版，需在
composer.json中显式声明，或设置"minimum-stability": "beta"和"prefer-stable": true平衡风险； -
构建元数据：用加号连接，如
1.0.0+20251217.1030或1.0.0+build.123。它不影响版本比较逻辑，仅用于记录构建信息，Composer 会忽略其参与解析。
为什么 ^ 和 ~ 的行为不同？关键看版本起点
Composer 版本约束符号基于 SemVer 设计，但对 0.x 和 1.x+ 处理有本质差异：
-
^1.2.3等价于>=1.2.3 ：允许次版本和修订号自由升级，前提是主版本不变； -
~1.2.3等价于>=1.2.3 ：只允许修订号变动，次版本被锁定； -
^0.3.4实际是>=0.3.4 （不是 <code>）：因 <code>0.x视为不稳定，次版本升级也可能破坏兼容性； -
~0.3.4同样是>=0.3.4 ，此时与 <code>^行为一致；但~0.3却等于>=0.3.0 ，风险极高，应避免。
生产项目中，^ 是默认推荐写法；若需更保守控制（如金融类系统），可用 ~ 锁定次版本，再配合 composer.lock 固化实际安装版本。
