SemVer规定版本格式为主.次.修订号，主版本变更表示不兼容修改，次版本为新增功能，修订号为bug修复；Composer通过^1.2.3等约束确保安装兼容版本，避免意外破坏代码。
在使用 Composer 管理 PHP 项目依赖时，理解 语义化版本（SemVer） 和 稳定性标志 非常关键。它们直接影响你引入的包是否会引发兼容性问题或意外更新。
什么是 SemVer（语义化版本）？
SemVer 是一种版本号命名规范，格式为 主版本号.次版本号.修订号，例如 2.1.5。
每一部分的递增都有明确含义：
- 主版本号（Major）：当你做了不兼容的 API 修改时递增
- 次版本号（Minor）：当你以向后兼容的方式添加新功能时递增
- 修订号（Patch）：当你修复向后兼容的 bug 时递增
这个规则让开发者能预判升级带来的影响。比如从 1.2.3 升级到 1.3.0，大概率会新增功能但不会破坏现有代码；而升级到 2.0.0，则可能需要修改调用方式。
Composer 中如何使用 SemVer？
Composer 利用 SemVer 来决定哪些版本可以安全安装。你在 composer.json 中写的版本约束会影响实际安装的包。
常见版本约束写法：
- ^1.2.3：允许更新到兼容的最新版本，等价于 1.2.3 ≤ 版本
- ~1.2.3：只允许修订和次版本更新，等价于 ≥1.2.3 且
- 1.*：匹配 1 开头的所有版本，如 1.0、1.5.2，但不包括 2.0
如果你希望依赖一个稳定版本，建议使用 ^ 操作符，它能在获取更新的同时避免破坏性变更。
稳定性标志及其作用
除了数字版本，Composer 还识别稳定性标志，如 dev、alpha、beta、RC、stable。
默认情况下，Composer 只安装稳定版本（即没有后缀的正式版）。如果你想使用不稳定版本，必须显式声明：
- dev-master：开发分支，随时可能变化
- 1.5.0-beta：测试版，可能存在 bug
- 2.0.0-rc.1：候选发布版，接近稳定
要启用非稳定版本，可以在 composer.json 中设置：
"minimum-stability": "beta",
同时建议配合 "prefer-stable": true，让 Composer 在可能的情况下优先选择稳定版本。
实际建议与最佳实践
为了保障项目稳定性和可维护性，推荐以下做法：
- 生产环境尽量只使用稳定版本，避免引入
dev分支 - 使用
^约束来平衡更新与兼容性 - 定期运行
composer update并结合锁文件composer.lock控制部署一致性 - 查看第三方包的 CHANGELOG，了解主版本升级的迁移说明
基本上就这些。掌握 SemVer 和稳定性规则，能让你更安心地管理依赖，减少“昨天还好好的”这类问题。
