答案是用composer why-not定位阻塞链并结合composer show --tree分析真实依赖结构；必须用完整版本号，输出为空需检查require-dev或conflict配置，升级降级单个包须加--with-dependencies。
直接改 composer.json 里的版本约束，别碰 vendor 或 composer.lock 后盲目重装——那只会复现冲突。
用 composer why-not 定位谁在拦路
报错里出现 don’t install guzzlehttp/guzzle:8.0.0？别猜，立刻查。命令必须带完整版本号：
-
composer why-not guzzlehttp/guzzle:8.0.0—— 输出是反向依赖链，最后一行是你composer.json里写的声明，往上逐行看哪条required by提出了互斥要求，那就是源头 - 输出为空？检查
require-dev区块——phpunit/phpunit或mockery/mockery常拖着老版sebastian/exporter，间接锁死symfony/console - 写
^8可能匹配不到元数据，必须写guzzlehttp/guzzle:^8.0.0或guzzlehttp/guzzle:8.0.0
用 composer show --tree 看真实依赖结构
composer.json 是你写的“愿望清单”，composer show --tree 才是 vendor/ 里实际存在的快照：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
composer show --tree | grep "symfony/console"—— 查谁引入了它、用了哪个具体版本 -
composer show --tree monolog/monolog | grep -A5 -B5 "guzzlehttp/guzzle"—— 过滤关键路径，看清间接依赖关系 - 看到
(replaced)或(provided)？得去那个包自己的composer.json里确认它是否真能替代你要的依赖
定点更新，不全量 composer update
全量 composer update 容易触发 SAT 求解器卡死，尤其老项目依赖多、约束杂：
- 升级单个包必须加
--with-dependencies：composer update monolog/monolog --with-dependencies—— 只动它和直系依赖 - 别写
composer update "monolog/monolog:^3"—— 引号 +^会让 Composer 自己找“最新兼容版”，不是你要的3.0.0 - 降级跨主版本（如从
guzzlehttp/guzzle:^8.0切回7.4.5），必须在composer.json里写死："guzzlehttp/guzzle": "7.4.5"，不能只写"^7.0" - 执行后立刻
git diff composer.lock，确认只有目标包及其直系依赖被改，没波及其他
最容易被忽略的是：镜像源和缓存只影响加载速度，不解决冲突本身；而 minimum-stability 配置错误、私有仓库未在根 repositories 中显式声明，这两点常被当成“网络问题”跳过排查。
