“Dependency resolution failed”本质是版本约束逻辑冲突，如monolog 2.0与1.25无法共存；用composer why-not定位冲突路径，再通过降级新包、升级旧包或replace策略解决。
为什么composer install或composer update会卡在“Dependency resolution failed”
这不是网络问题，也不是权限问题，而是 Composer 在尝试满足所有 require 和 require-dev 中的版本约束时，发现没有一组可同时安装的包版本。它不是“装不上”，而是“逻辑上不存在解”——比如 A 包要求 "monolog/monolog": "^2.0"，B 包却硬性依赖 "monolog/monolog": "^1.25"，这两个约束无法共存。
常见诱因包括：
• 项目长期未更新，composer.lock 锁定了过旧的版本，而新引入的包只兼容更新的生态
• 直接修改了 composer.json 中的版本号（如写死 "laravel/framework": "9.0.0"），但没考虑其子依赖的兼容边界
• 使用了 dev 分支或 dev-master 这类不带语义化约束的版本，导致解析器无法收敛
用composer why-not定位具体冲突包
别猜，直接问 Composer：“哪个包在挡路？”最有效的方式是用 composer why-not 检查你想装但失败的那个包。比如你执行 composer require phpunit/phpunit 失败，就立刻运行：
composer why-not phpunit/phpunit ^10.0
输出会列出所有阻止该版本安装的已存在依赖及其约束条件，例如：
laravel/framework v9.52.5 requires nunomaduro/collision ^6.0 -> satisfiable by nunomaduro/collision[6.0.0, ..., 6.4.0].<br>nunomaduro/collision 6.4.0 requires phpunit/phpunit ^9.3 -> conflict with phpunit/phpunit[10.0.0].
这就清楚说明：Laravel 9.52.5 → collision 6.4.0 → 只认 PHPUnit 9.x，和你要的 10.x 冲突。
- 如果输出为空或提示 “no version set”，说明该包根本不在当前依赖图中，可能是拼写错误或仓库不可见
-
composer why-not必须指定完整包名 + 版本约束（如^10.0），不能只写包名 - 它不解决冲突，但能帮你把“一大片报错日志”压缩成一行关键路径
三种安全降级/升级策略，避开硬冲突
找到冲突点后，不要急着删 vendor 或强制 --ignore-platform-reqs。优先走语义化兼容路径：
- 对新引入的包，尝试更低主版本：比如
composer require phpunit/phpunit:^9.6而非^10.0，尤其当项目基于 Laravel 9 或 Symfony 6 时 - 对已有包，检查是否可小步升级：运行
composer outdated，挑出明显落后的核心包（如symfony/console卡在 5.4），再单独升级它们：composer update symfony/console --with-dependencies - 若必须用新包且旧框架无法升级，加
"replace"到composer.json（仅限高级场景）：比如你确认某个废弃组件已被自定义实现替代，可用"symfony/polyfill-ctype": "*"替换掉原生扩展依赖，但需自行保证功能等价
注意：composer update --dry-run 是低成本验证手段，它只计算依赖图，不改任何文件，适合在 CI 或本地快速试错。
composer update 后 autoload 不生效？检查 vendor/autoload.php 是否被缓存或覆盖
依赖装成功了，但 class not found？这常发生在冲突解决后忘记刷新自动加载机制。Composer 不会在每次 update 后自动重生成 vendor/autoload.php 的映射，尤其当你手动删过 vendor 或用了 --no-autoloader 选项。
执行以下任一操作即可修复：
-
composer dump-autoload：重建 PSR-4/PSR-0 映射，适用于新增了本地src/类但没更新 autoload 配置的情况 -
composer install --optimize-autoloader：重新安装并启用 classmap 优化（生产环境推荐） - 检查
composer.json中"autoload"字段是否误写了路径（如"src/."少了个斜杠变成"src/."→ 实际匹配不到）
最隐蔽的坑是某些 IDE 或 Docker 容器里，vendor/autoload.php 被挂载卷覆盖或权限锁死，导致即使 Composer 说“已生成”，实际文件内容仍是旧的。此时需确认文件 mtime 和内容一致性。
