Composer 默认安装满足约束的最高版本，如 "^2.0" 会选 2.10.2 而非 2.0.0；其依赖解析器按语义化版本降序排列候选版本并取首个。
Composer 选择满足约束的最高版本
当 composer.json 中的版本约束（如 "monolog/monolog": "^2.0"）匹配多个可用版本时，Composer 默认安装满足条件的最新稳定版（即语义化版本中最高的 minor/patch 组合），而非最低或随机版本。
这个行为由 Composer 的依赖解析器（PoolBuilder + VersionSelector）驱动，它会拉取所有匹配的候选版本，按语义化顺序降序排列，并优先选第一个——也就是最高合法版本。
- 约束
"^2.0"匹配2.0.0到2.999.999（不含3.0.0），Composer 会选其中最高的，比如2.10.2 - 约束
"~2.8"等价于>=2.8.0 ，只会考虑 <code>2.8.x，选其中最高 patch，如2.8.7 - 如果同时存在
stable、beta、dev-main，Composer 默认只看stable标签；除非显式允许不稳定版本（见下节）
如何强制使用更低版本或特定预发布版
Composer 不会自动降级，除非你手动干预。常见手段有：
- 在
composer.json中写死版本号："monolog/monolog": "2.3.5" - 用
require --no-update锁定后，再composer update monolog/monolog指定范围更新 - 启用预发布支持：在根
composer.json中添加"minimum-stability": "beta"或"prefer-stable": false，否则2.9.0-beta1这类不会被选中 - 使用
composer require vendor/package:2.8.*显式指定范围，会覆盖原有约束并重算依赖
注意：prefer-stable: true（默认）会让 Composer 在满足约束的前提下，优先避开 beta/rc 版本，哪怕它们语义上更高。
为什么 composer.lock 一旦存在就不再重新选版本
composer.lock 是 Composer 的“确定性快照”，它记录了每个包的精确版本、源类型（dist/git）、commit hash 和完整依赖树。只要该文件存在且未被删除或修改，运行 composer install 就严格按锁文件还原，完全跳过版本选择逻辑。
-
composer update才会重新走版本解析流程，刷新lock文件 - 即使远程仓库新增了
2.10.3，只要lock里锁的是2.10.2，install就不会升级 - 多人协作中，提交
composer.lock是保证环境一致的关键；忽略它等于放弃可复现性
常见误判：看到旧版本不是因为“没选新”，而是约束太窄
如果你发现 Composer 安装了远低于预期的版本（比如只装了 2.1.1，而 2.10.2 已发布），大概率是其他已安装依赖的版本约束把你“拖住了”。
例如：
"require": {
"monolog/monolog": "^2.0",
"some-old-lib": "1.2.0"
}
而 some-old-lib 1.2.0 的 composer.json 声明了 "monolog/monolog": "^1.23" —— 这个冲突会让 Composer 回退到同时满足两者的最高版本，可能就是 2.1.1（因为 2.2+ 不兼容 some-old-lib 的约束）。
查清原因用：composer why monolog/monolog 看谁在限制它，或 composer prohibits monolog/monolog:2.10.2 查具体冲突点。
真正难的从来不是“怎么选”，而是理解哪个依赖在暗处卡住了你的升级路径。
