先运行composer why-not定位阻断链，再查prohibits和require-dev隐藏冲突，确认版本交集后锁定具体版本号并用--with-dependencies更新，最后验证lock变更与API兼容性。
别改 composer.json 之前先搞清谁在封杀版本——直接手改容易把问题从“装不上”变成“跑不起来”。
composer why-not 能告诉你真正卡住的是谁
报错里写 don't install monolog/monolog:2.9.0，不是它不能装，而是别的包联手把它锁死了。运行：
-
composer why-not monolog/monolog:2.9.0—— 输出是一条反向链，从最后一行（你写的require）往上读，看到哪一行出现requires不同版本的monolog/monolog，那就是冲突点 - 如果输出为空，检查
require-dev：比如phpunit/phpunit可能悄悄拉进一个老版symfony/console，间接卡住主依赖 - 配合
composer prohibits monolog/monolog:2.9.0看所有明确反对这个版本的包
手动改 composer.json 前必须确认交集是否存在
比如 A 包要求 "monolog/monolog": "^1.25"，B 包要求 "monolog/monolog": "^2.10"，这两个范围根本没有交集——改 composer.json 写 "^2.0" 没用，Composer 仍会失败。
Json Schema Toolkit
下载
使用 JSON Schema 验证 JSON 数据，从示例 JSON 生成 schema，并将其转换为 TypeScript 接口、Python 数据类或 Markdown 文档。
- 去 Packagist 查哪些版本同时被两个约束接受（例如
2.9.3可能被^2.0和>=2.8.0同时覆盖） - 不要写
"monolog/monolog": "^2.0"，改成具体版本号："monolog/monolog": "2.9.3" - 改完只跑
composer update monolog/monolog --with-dependencies，避免牵连其他包
require-dev 是隐藏冲突高发区
主项目用 laravel/framework: ^11.0，但 orchestra/testbench: ^8.0 还没适配，它内部硬绑 laravel/framework: ^10.0 —— 这种冲突不会在 require 里体现，却会让整个解析失败。
- 运行
composer show --tree | grep -A3 -B3 "laravel/framework"，看有没有(dev)或(require-dev)标记的路径 - 临时注释掉
require-dev里的可疑包，再试composer install --dry-run - 确认是它导致的，就换兼容版本（如
orchestra/testbench: ^9.0），或等官方更新
改完立刻验证 lock 文件是否只动了该包
执行 composer update 后，composer.lock 会变。但如果你只打算升级 monolog/monolog，那 diff 里就不该出现 guzzlehttp/guzzle 或 symfony/console 的变动。
- 跑
git diff composer.lock，重点看packages和packages-dev下是否只有目标包及其直系子依赖 - 如果出现大量无关变更，说明你漏掉了
--with-dependencies，或者某个子依赖本身也存在隐性冲突 - 生产环境提交前，务必让 CI 跑一遍
composer install，而不是只信本地update结果
最麻烦的不是找不到解法，而是改完 composer.json 发现代码里 Monolog\Logger::channel() 在 v2 和 v3 之间签名不同——版本能装上，运行时才崩。所以任何手动指定版本的操作，都得同步检查 API 兼容性文档。
