根本原因是命令格式错误导致Composer将版本号误解析为分支名或别名；必须用composer require monolog/monolog:2.9.1，且composer.json中需严格写为"monolog/monolog": "2.9.1"，无修饰符、无空格、无v前缀、不省略补丁号。
composer require 后为什么没装上你写的版本
根本原因不是 Composer 失效，而是你输的命令被它当成了分支名或别名解析。比如 composer require monolog/monolog:2.9.1 是唯一能触发精确安装的写法；monolog/monolog@2.9.1 会被当成 Git 仓库地址忽略，monolog/monolog=2.9.1 在部分旧版中直接报 Could not parse version constraint，而 monolog/monolog : 2.9.1（冒号后有空格）同样失败。
包名大小写敏感、版本号不能带 v 前缀也是高频雷区：Monolog/Monolog 或 monolog/monolog:v2.9.1 都会导向 dev-v2.9.1 分支，几乎找不到对应 tag。
怎么确认 composer.json 里真写死了精确版本
执行完 composer require 后，必须手动打开 composer.json 查看对应行——格式必须是 "monolog/monolog": "2.9.1"，且满足三个条件：
- 引号只包裹整个字符串值，版本号本身不被额外引号包围
- 没有
^、~、@、=等任何修饰符 - 不是
"2.9"这种省略补丁号的写法（它等价于~2.9.0）
如果看到 "monolog/monolog": "^2.9.1"，说明你误用了 ^，或者命令输错导致 Composer 自动降级并简化了写法。
装完还是旧代码？检查这三处再动手
现象：命令跑成功了，composer.json 和 composer.lock 看着都对，但 vendor/monolog/monolog/composer.json 里 version 字段仍是 2.12.0——这不是命令失效，而是环境残留干扰：
-
composer.lock已提交到 Git 且含旧版本记录：下次composer install会无视composer.json中的新约束，直接还原 lock 文件里的旧版 - 本地缓存存在旧 ZIP 包：Composer 可能跳过校验直接解压，尤其在离线或网络异常时
- 目标 tag 实际不存在：用
composer show -a monolog/monolog查不到2.9.1，或 Packagist 页面显示该版本状态为abandoned
解决办法是先删 vendor/monolog/monolog 目录和 composer.lock 中对应项，再重跑 composer require，最后 composer install。
降级已有包时最安全的操作顺序
项目里已装 guzzlehttp/guzzle 7.8.0，你想精准降到 7.4.5，又不想连带升级其他依赖——全量 composer update 极易引发冲突：
- 先运行
composer require guzzlehttp/guzzle:7.4.5 --no-update，只改composer.json - 再单独更新这个包：
composer update guzzlehttp/guzzle - 若报依赖冲突，用
composer why guzzlehttp/guzzle查谁在强依赖高版本，而不是硬加--with-all-dependencies
真正锁定行为靠的是 composer.json 里的纯版本号 + composer.lock 的 commit hash 两层确认，缺一不可。哪怕写了 =2.9.1，只要 lock 文件没更新、没提交，CI 上跑 composer install 就仍可能拉出旧版。
