Composer版本冲突更新失败，90%是依赖链中某包锁死不兼容版本；应先运行composer why-not定位阻塞源，而非删vendor或lock文件。
直接结论：composer.lock 更新失败，90% 不是网络或语法错误，而是某个包在依赖链里锁死了不兼容的版本范围；别删 lock 文件重来，先用 composer why-not 定位谁在拦路。
报 “Conclusion: don’t install vendor/package:version” 怎么快速定位阻塞源
这个报错说明 Composer 已完成元数据拉取，正卡在 SAT 求解阶段——此时最有效动作是反向查谁在阻止安装，而不是重试或清缓存。
- 运行
composer why-not guzzlehttp/guzzle:^7.5（把目标包和版本换成你报错里的内容），输出是一条从根依赖往上的链，最上面一行才是源头，比如Root package requires php ^7.4就意味着你composer.json里写了过窄的 PHP 约束 - 如果输出为空，检查
require-dev区块——很多冲突来自phpunit/phpunit或mockery/mockery间接锁死sebastian/exporter，进而拖住整个 Symfony 生态 - 别用
composer depends替代，它只显示“谁依赖它”，不体现版本限制，对冲突诊断完全无效
定点更新却波及十几个包？参数和边界没控住
执行 composer update 不加参数等于让 Composer 重算整个依赖图，极易触发求解器卡死或误升大版本（比如把 guzzlehttp/guzzle 从 7.x 升到 8.x，导致 new GuzzleHttp\Client() 报错）。
- 正确写法：
composer update monolog/monolog --with-dependencies——只动它和它的直系依赖 - 错误写法：
composer update "monolog/monolog:^3"——引号 +^会让 Composer 自行找“最新兼容版”，不是你要的 3.0.0 - 加
--dry-run预览：composer update monolog/monolog --with-dependencies --dry-run，确认改动范围再执行 - 升级后立刻
git diff composer.lock，只接受目标包及其直系依赖变更；如果波及十几个包，说明约束没控住，得回退
为什么 composer show --tree 比看 composer.json 更可靠
composer.json 写的是你想要的，composer.lock 和 vendor/ 才是你真正得到的。依赖结构得看真实快照，不是愿望清单。
- 运行
composer show --tree查真实依赖树，它暴露你根本没意识到的间接路径（比如laravel/framework暗中引入了symfony/console v6，而你本地另一个包要求 v5） - 过滤关键段：
composer show --tree monolog/monolog | grep -A5 -B5 "guzzlehttp/guzzle"，看是否被替换((replaced))或提供((provided)) - 查某个包被谁引入：
composer show --tree | grep "symfony/console"，注意后面是否标着(locked to 5.4.42)
删 composer.lock 后千万别跑 composer update
删了 composer.lock 后误跑 composer update，结果往往更糟：update 会复用缓存、忽略 "platform" 配置，可能装出 PHP 版本不兼容的包。
- 删 lock 后唯一正确的入口是
composer install，它会在无 lock 时退化为按composer.json解析，但行为更可控、不跳过平台检查 - 如果
composer.json里写了"dev-main"这类分支约束，update可能拉取不同 commit，导致 lock 文件再次混入多个source.reference - 真要重建，标准三连是：
rm -rf vendor composer.lock+composer clear-cache+composer install --no-cache
真正容易被忽略的是：锁文件不是“一次生成永久有效”的契约，它是某次解析的快照，只保证“当时能跑”。一旦底层环境（PHP 版本、扩展、镜像源可用性）变化，它就可能失效——这时候靠猜不如靠 why-not 和 show --tree 看实锤。
