旧项目重构时composer依赖冲突的本质是契约不兼容，需用composer why-not定位阻断链、show --tree查看真实依赖、定点更新替代全量升级，并谨慎处理conflict字段与私有包。
旧项目重构时的 Composer 依赖冲突，本质不是“包装不上”，而是你正在试图把两套不兼容的契约硬塞进同一个容器里——必须先看清谁签了哪份合同，再决定撕哪张。
composer why-not 是唯一可信的起点
报错里出现 don't install symfony/console:v6.4.0 或 Root requires guzzlehttp/guzzle ^7.0 这类信息，只是结果。真正要盯住的是：谁在阻止它？
- 运行
composer why-not symfony/console:6.4.0，输出会从底向上列出完整阻断链，最后一行是你的composer.json根声明，往上每行都标着(required by xxx v1.2.3)—— 那就是冲突源头 - 如果输出为空，立刻检查
require-dev区块：phpunit/phpunit、orchestra/testbench、mockery/mockery这些测试工具常悄悄锁死symfony/*或laravel/framework的老版本 - 别信
composer depends：它只告诉你“谁用了它”，不告诉你“谁不准它升”，而冲突永远来自“不准”
show --tree 看见真实依赖，不是愿望清单
composer.json 里写的只是你的愿望，composer.lock 和 vendor/ 才是现实。用 composer show --tree 能暴露你根本没意识到的间接路径。
- 执行
composer show --tree | grep "guzzlehttp/guzzle"，看它是否标着(locked to 7.2.0)—— 如果是，说明某个子依赖（比如spatie/laravel-backup）把它钉死了 - 过滤特定路径：
composer show --tree monolog/monolog | grep -A5 -B5 "symfony/event-dispatcher"，确认是否因事件分发器版本不匹配导致升级失败 - 注意
(replaced)和(provided)标记：比如symfony/polyfill-mbstring声明provides: ext-mbstring，但若你代码里真调用了mb_ereg()这种 polyfill 不覆盖的函数，运行时仍会崩
定点更新比全量 update 安全十倍
在旧项目里跑 composer update 等于让 SAT 求解器在迷宫里随机撞墙，尤其当依赖超 30 个时，可能卡在 Resolving dependencies 超过 10 分钟。
- 升级单个包必须带
--with-dependencies：composer update laravel/framework --with-dependencies—— 否则 Composer 默认拒绝更新其子依赖，哪怕新框架根本跑不起来 - 降级跨主版本（如从
guzzlehttp/guzzle:^8.0切回7.4.5），必须在composer.json里写死"guzzlehttp/guzzle": "7.4.5"，不能只写"^7.0"，否则求解器可能选到一个被其他包排斥的中间版本 - 验证改动范围：
git diff composer.lock后只看到目标包及其直系依赖变更，才算安全；如果连symfony/yaml或psr/log都动了，说明约束太松或有隐藏冲突
私有包和 conflict 字段是隐形地雷
很多旧项目会自己写私有组件，并在 composer.json 里加 "conflict": {"laravel/framework": ">=11.0"}。这看起来是防护，实则是定时炸弹。
-
conflict是全局生效的：哪怕你项目里根本没 requirelaravel/framework，只要某个已安装的包（比如spatie/laravel-ray）间接拉入了 L11，就会触发拒绝 - 检查所有私有包的
composer.json，删掉那些“提醒式”的conflict—— 真正互斥的场景极少，大部分只是开发者怕出事随手加的 - 如果必须保留，确保它只针对明确不兼容的组合，且同步在文档里写清替代方案，而不是指望别人读报错去猜
重构旧项目最易被忽略的点：你改的从来不是版本号，而是整个依赖图的信任链。每次 composer update 都是在重签一份新合同，而旧代码可能还按着上一份合同在跑。别急着让所有包都升到最新，先让最关键的三四个核心包能共存，再一层层剥开子依赖的硬壳。
