Composer版本降级迁移冲突_Composer版本回退导致依赖冲突【技巧】

Composer版本降级时遇到的依赖冲突，本质上不是“回退失败”这个动作本身出了问题，而是你正尝试安装的版本组合，已经被项目里其他依赖明确拒绝了。这种情况下，Composer不会替你妥协，唯一能走的路径，就是人工对齐那些相互矛盾的约束。

composer why-not 是唯一可信的起点

报错里那句 Conclusion: don't install lara vel/framework v10.32.0，其实只是个最终结论。真正需要深挖的，是运行 composer why-not lara vel/framework:10.32.0 之后输出的完整阻断链。这条链从你的根项目开始，一路倒推，每一行末尾的 (required by ...) 都在指向更上层的依赖，直到最后一行的源头，就是你 composer.json 里写下的那个 require。

• 如果某一行显示 package-x v2.1 -> requires symfony/console ^5.4，而你要降级的框架要求 symfony/console ^6.4，那么冲突点其实落在了 symfony/console 上，跟 Lara vel 本身无关
• 用 composer show --tree | grep symfony/console 可以快速确认当前已装的版本，以及它的来源——尤其是 require-dev 里的测试工具，很可能悄悄锁死了一个旧版
• 如果输出为空？那说明这个版本压根没在 Packagist 上存在过，不是冲突，是版本不存在

降级 ≠ 直接改 composer.json 然后 run update

手动把 "lara vel/framework": "^10.0" 改成 "lara vel/framework": "9.52.16" 后直接执行 composer update，大概率会触发一次全量重算。SAT 求解器要么卡住，要么拉进来一堆不兼容的子依赖。

• 先去 Packagist 查清楚目标降级版本（比如 9.52.16）所依赖的底层包范围。它是否还接受 guzzlehttp/guzzle:^7.0？而你其他包是不是已经升到了 ^8.0？
• 用 composer update lara vel/framework --with-dependencies 定点执行，让 Composer 只重算 Lara vel 及其直系依赖，别去碰 phpunit 或 mockery 这类看似无关的包
• 改完后立刻 git diff composer.lock，检查是否只改了预期的包——多出一个 symfony/polyfill-ctype 的小版本，都可能暴露运行时 autoload 错误

冲突常来自 require-dev 或隐性 replace 规则

很多降级失败，主业务包并不是元凶。真正的问题往往在 require-dev 里：某个测试工具强制绑定了高版本组件，或者某个包在 replace 字段里声明替代了 PHP 扩展，但 polyfill 并没有完全覆盖。

• 在 composer show --tree 的输出里搜一下 phpunit、pestphp/pest，看看它们是不是拖着 symfony/console 或 sebastian/exporter 卡在 6.x
• 检查 conflict 字段：比如你私有 SDK 声明了 "conflict": {"lara vel/framework": ">=10.0"}，哪怕你没直接 require 它，只要其他已装包间接拉进来，就会触发全局拒绝
• replace 不是魔法：如果用 symfony/polyfill-mbstring 替代 ext-mbstring，但某个包内部硬调用了 mb_ereg_replace（polyfill 未实现），运行时照样崩

删 vendor 和 lock 是最后手段，且必须带验证

清掉 vendor/ 和 composer.lock 后直接 composer install，等于放弃所有历史线索，让 Composer 从零开始暴力求解。它可能给出一个“能装上”的组合，但这个组合未必是你代码实际能跑通的。

• 删之前先 composer show --tree > before-tree.txt，把现场记录下来
• 重装后立刻跑 composer why-not 验证关键包（比如 guzzlehttp/guzzle、monolog/monolog）是否仍被某处隐性封杀
• 加上 --dry-run -v 观察解析过程：如果日志里反复出现 Trying monolog/monolog 2.9.3 → Backtracking，说明约束根本无交集，删 lock 并不能解决实质问题

真正难的从来不是命令怎么敲，而是看懂 why-not 输出里哪一行是“真阻断”，哪一行只是“顺带声明”；以及判断某个 replace 是否真的覆盖了所有运行时调用路径。这些没法靠 --ignore-platform-reqs 绕过，得一行行对照源码和 Packagist 的发布记录。