语义化版本（SemVer）用M.N.P三位数字约定版本含义：M为不兼容API变更，N为向后兼容新增功能，P为纯修复；composer据此解析如^2.8等约束，自动选择安全更新范围。
语义化版本（SemVer）是一套用三位数字（主版本.次版本.修订号，如 2.4.1）表达版本演进含义的约定，不是随便编的编号。Composer 依赖它自动判断哪些更新是安全的、哪些可能破坏代码。
版本号背后的含义：每个数字代表什么变化
一个 SemVer 版本形如 M.N.P（例如 3.1.0），三个数字有明确职责：
- M（主版本号）：不兼容的 API 变更。比如移除函数、改方法签名、重命名类——升级后代码大概率报错。
- N（次版本号）：新增向后兼容的功能。加了新方法、新类，但旧代码照常运行。
- P（修订号）：纯修复，比如修 bug、优化性能，完全不影响接口行为。
Composer 怎么用它做依赖决策？
当你在 composer.json 中写 "monolog/monolog": "^2.8"，Composer 不是简单找最新版，而是按 SemVer 规则算出“允许安装的范围”：
-
^2.8表示：主版本必须是2，次版本 ≥8，修订号任意 —— 即2.8.0到2.99.99都行，但3.0.0不允许（主版本变了）。 -
~2.8.0更保守：允许2.8.x，但不允许2.9.0（次版本也不能升）。 -
2.8.*等价于2.8.0 - 2.8.999，只允许修订号变动。
Composer 安装时会查包的 composer.json 中声明的 version 字段（或 git tag），严格按 SemVer 解析，再比对你的约束条件，选一个满足规则且最新的可用版本。
为什么这很重要？举个真实场景
假设你用 symfony/http-kernel 的 5.4.0，项目里调用了 Kernel::handle() 方法。某天它发布 6.0.0，把 handle() 改成 handleWithException() 并删掉旧方法。如果你的依赖写的是 ^5.4，Composer 死也不会装 6.0.0；但如果误写成 * 或 >=5.4，更新就直接崩。
反过来，如果它发了 5.4.1 修了个请求头解析的 bug，^5.4 会自动拉取，你不用改代码就能受益。
小提醒：不是所有包都守规矩
SemVer 是约定，不是强制标准。有些包可能：
- 跳着发版（比如从
1.0.0直接到3.0.0），或 - 在
patch版里偷偷改行为（违反 SemVer），或 - 根本没打 Git tag，靠 Composer 自己猜版本（不推荐）。
所以看包文档、留意 CHANGELOG、优先选知名库，比光看数字更重要。
基本上就这些。版本号不是密码，是沟通协议 —— 你告诉 Composer 你愿意承担多大风险，它帮你守住边界。