必须用无符号纯数字（如monolog/monolog:1.2.3）或等号写法（monolog/monolog=1.2.3）才能精确锁定版本；含^、~等符号会触发自动升级，非bug而是设计行为。
要安装指定版本的包，必须用精确写法（如 monolog/monolog:1.2.3 或 "monolog/monolog": "1.2.3"），任何带 ^、~、> 的写法都会导致 Composer 自动升级到其他兼容版本——这不是 bug，是设计行为。
composer require 命令里怎么写才算“精确”
命令行添加依赖时，: 后面的版本字符串决定是否锁定。不加符号 ≠ 精确；只有显式使用无修饰数字或等号才真正锁死。
-
composer require monolog/monolog:1.2.3→ 正确，写入"monolog/monolog": "1.2.3"到composer.json，后续install严格还原 -
composer require monolog/monolog=1.2.3→ 等价于上一条，=是可选语法糖 -
composer require monolog/monolog:^1.2.3→ 错误，实际允许升到1.9.9，只要主版本还是1 -
composer require monolog/monolog:1.2.3 --no-update→ 安全操作：先写进composer.json，再手动composer update monolog/monolog控制范围
为什么写了版本号却装了别的？常见原因
现象是执行完 composer require xxx:1.2.3，结果 vendor/ 里却是 1.2.4 或 2.0.0——大概率不是命令失效，而是环境干扰。
- 包已存在且
composer.lock记录了更宽泛约束（如"^1.2"），require默认会复用 lock 文件逻辑，而非强制重装 - 本地缓存里有旧版 ZIP，Composer 拿缓存解压后没校验版本号是否匹配
- 该版本根本没发布在 Packagist 上，Composer 回退到最近可用版本（比如你写
1.2.3，但作者只打了1.2.2和1.3.0） - PHP 版本不匹配：
composer show monolog/monolog能看到所有 tag，但运行composer require monolog/monolog:1.2.3失败，可能因该 tag 的composer.json里声明了"php": ">=7.4"，而你本地是8.2，某些子依赖却只支持7.x
想换版本但怕影响其他包，怎么安全操作
全局 composer update 会重算整个依赖图，容易连带升级一堆无关包。局部更新必须显式限定目标，并注意约束边界。
- 只更新单个包：
composer update monolog/monolog—— 它仍受composer.json中该包的约束限制，不会突破"^1.2"去装2.x - 多个包一起更新：
composer update guzzlehttp/guzzle symfony/console，空格分隔，不支持通配符 - 先卸载再装精确版更可控：
composer remove monolog/monolog && composer require monolog/monolog:1.2.3 - 如果已有冲突提示，别硬上
--with-all-dependencies，先跑composer why-not monolog/monolog:1.2.3看哪条依赖卡住了它
composer.json 里写死版本后，为什么 CI 还是装错？
关键点不在 composer.json，而在 composer.lock 是否提交、以及 CI 执行的是 install 还是 update。
-
composer install完全忽略composer.json的约束，只按composer.lock里的 SHA 和 URL 还原——所以lock文件必须提交到 Git - CI 脚本里如果写了
composer update（哪怕只跟一个包名），就等于放弃 lock 文件，重新走依赖求解，可能引入新版本 - 团队协作中，有人本地执行了
composer update又忘了提交新的lock，其他人install就会还原成旧版 - PHP 版本差异也会导致 lock 不一致：同一份
composer.json，在 PHP 8.0 和 8.2 下运行composer update可能生成不同lock内容，因为 platform 兼容性判断不同
