Composer 2.9.6 升级后暴露老旧依赖冲突，根本原因是新 SAT 解析器更早精准识别语义冲突（如 php:^7.4 与 PHP 8.5.5 不兼容），而非变严格；需用 composer why-not、prohibits、show --platform 定位真实封杀者，并清理 lock 文件重装。
Composer 升级到 2.9.6 后出现老旧依赖类冲突，根本原因不是客户端“变严格”了，而是新解析器更早、更准地暴露了原本被旧版容忍的语义冲突——比如某个包声明 require 了 php: ^7.4，但你的项目实际运行在 PHP 8.5.5，而旧版 Composer 没拦住，新版直接拒绝解析。
看懂报错里真正的“封杀者”是谁
错误信息中出现的 is not satisfiable 或 conflict 往往只列最后失败的包，但真正卡死的是上游约束。关键动作是立刻执行：
-
composer why-not vendor/old-package:1.2.0—— 替换为你报错中提到的老包名和版本，它会输出所有阻止安装该版本的包及其require约束 -
composer show --platform—— 确认当前 PHP 版本（php）、已启用扩展（如mbstring、intl）是否满足所有依赖的platform要求 - 如果报错含
Root package requires php: ^7.4，说明你composer.json里写了过时的php版本限制，必须改掉
别跳过 --dry-run -v，它能提前暴露 SAT 回溯瓶颈
Composer 2.9.6 的 SAT 求解器在复杂依赖图下更容易进入长时回溯，表现为 Resolving dependencies 卡住不动或超时。这不是网络问题，是算法在穷举无解路径。
- 先跑
composer update --dry-run -v，观察日志末尾是否反复出现Trying+Reverting—— 这是典型回溯信号 - 若卡在某个包（如
symfony/console），立即用composer prohibits symfony/console:^6.0查谁在禁止它 - 避免直接
composer update全量重算；改用composer update vendor/key-package --with-dependencies锁定关键路径
清理 lock 文件不是妥协，而是重置解析起点
当 composer.lock 是从 Composer 2.2 或更早版本生成并长期未更新时，它的约束快照与新版求解逻辑不兼容，强行复用只会让冲突更隐蔽。
- 删掉
composer.lock和vendor/目录（别怕，这是必要步骤） - 执行
composer install --no-scripts --no-plugins，跳过可能触发冲突的生命周期脚本 - 再逐个加回关键包：
composer require laravel/framework:^10.0，而不是一次性update - 过程中若又报冲突，回到第一步用
why-not定位，不要靠删包硬推
老旧类名冲突往往来自 autoloader 映射残留
升级后提示 Class OldPackageHelper not found，但 composer show old/package 显示已安装？大概率是 PSR-4 映射没刷新或存在重复声明。
- 运行
composer dump-autoload -o强制重建优化映射表 - 检查
composer.json的autoload和autoload-dev，删掉所有显式指向src/old/或lib/的路径声明（新包通常只留"App\": "app/"） - 确认没有两个包通过
psr-4把同一个命名空间映射到不同目录，这会导致类加载优先级混乱
最常被忽略的一点：Composer 2.9.6 默认启用更严格的平台检查，哪怕你本地 PHP 版本达标，只要某个依赖的 composer.json 里写了 "ext-intl": "*" 而你没装 intl 扩展，它就会直接失败——不会像旧版那样悄悄跳过。务必先 composer diagnose 过一遍环境匹配性，再动依赖。
