^2.0 允许安装 2.x.y 版本，但因语义化版本规则，2.10.0 中的 10 被视为两位数 minor，仍属允许范围；实际跳过 2.9.0 是因其他依赖约束或已锁定版本所致，并非 ^ 规则本身排除。
Composer 默认按语义化版本（SemVer）解析 composer.json 中的版本约束，但实际行为常与直觉不符——比如写 "monolog/monolog": "^2.0" 并不表示“只要大版本是 2 就行”，而是严格遵循 ^ 的升级边界规则。
为什么 ^2.0 不会安装 2.10.0 却可能跳过 2.9.0？
^ 运算符不是“允许同主版本内任意更新”，而是“允许在不改变最左非零数字的前提下升级”。对 ^2.0 来说，最左非零位是 2（主版本），因此只允许升级 minor 和 patch，即 2.x.y 范围；但对 ^2.0.0 才等价于 >=2.0.0 。而 ^2.0 实际被解释为 >=2.0.0 ，没错——它确实包含 2.10.0。真正容易误判的是 ^0.2.3：它只允许 >=0.2.3 ，连 0.2.10 都不满足（因为 0.2.10 成立，但 0.2.10 字典序大于 0.2.3，且符合规则）。
关键点：
-
^1.2.3→>=1.2.3 -
^0.2.3→>=0.2.3 （注意：0.x 系列的 minor 升级被视为“不兼容变更”） -
^0.0.3→>=0.0.3 （仅 patch 可动） - 没有
.x或通配符时，Composer 不做模糊匹配；"^2"和"2.*"行为不同："^2"是>=2.0.0 ，"2.*"是>=2.0.0 （等价），但"2.x"是>=2.0.0 ，而"~2.0"是>=2.0.0 ——等等，这里容易混淆：实际上~2.0等价于>=2.0.0 ，这才是重点。
~ 和 ^ 在日常开发中怎么选？
用 ~ 锁定最小兼容范围，适合对下游依赖行为敏感的场景；用 ^ 接受更宽泛的向后兼容更新，适合通用工具类包。
- 如果你依赖一个 SDK，且文档明确说 “
2.4.x保持 API 兼容”，那就写"vendor/sdk": "~2.4"→ 安装2.4.0到2.4.999，但不会升到2.5.0 - 如果你用
symfony/console，官方保证^6.0内所有版本都兼容，写"symfony/console": "^6.0"更合理 -
~1.2.3等价于>=1.2.3 ；~1.2等价于>=1.2.0 ；~1等价于>=1.0.0 - 不要混用：
"^2.0.0 || ~2.1"这种写法会让 Composer 解析失败或产生意外交集
运行 composer update 时版本没变？检查这三处
常见现象：改了 composer.json 的版本约束，执行 composer update foo/bar 后 composer.lock 里版本纹丝不动。原因往往不在约束本身。
- 当前已安装的版本仍满足新约束（例如原为
2.8.0，你把约束从^2.7改成^2.8，它依然合法） -
composer.lock中该包被显式锁定（比如有"reference"字段指向某 commit），此时需加--with-all-dependencies或先删 lock 文件 - 存在更高优先级约束：其他已安装包要求
foo/bar: ^2.5，而你新写的^2.9被其压制，Composer 会选择满足所有依赖的最大交集版本
如何强制安装某个确切版本并防止后续漂移？
生产环境应避免使用 ^ 或 ~，尤其当 CI/CD 流水线需要可重现构建时。
- 写死版本号：
"phpunit/phpunit": "9.6.15"（无任何运算符）→ Composer 只认这个 exact 版本 - 配合
composer.lock提交：确保所有协作者和部署环境使用同一套解析结果 - 禁用自动更新：在
composer.json里加"config": {"lock": true}（注意：这不是标准字段，真正生效的是提交 lock 文件 + 不手动运行update） - 验证是否生效：运行
composer show phpunit/phpunit，输出中versions行应只显示一个版本，而非版本范围
{
"require": {
"guzzlehttp/guzzle": "7.8.1",
"laravel/framework": "10.42.0"
},
"config": {
"sort-packages": true,
"platform-check": false
}
}
真正难的不是记住 ^ 和 ~ 的数学定义，而是理解每个依赖包自身是否真正在遵守 SemVer——很多 PHP 包把 0.x 当试验田，一次 0.9.0 → 0.10.0 就破坏接口，这时 ^0.9 反而比 ~0.9 更危险。
