如何分析Composer require失败日志，找出具体安装失败原因？

本文共计1073个文字，预计阅读时间需要5分钟。

require失败，不是包未下载，而是Composer在依赖图中找不到满足所有约束的版本组合——它卡在逻辑推演阶段，不是网络或权限问题。

看懂 Conclusion 和 Found conflicting requirements 这两段

Composer 报错末尾那几行才是关键线索，别滑到最上面去翻“cURL error 60”或“Connection timed out”。Conclusion 是它回溯后认定的死结，比如：Conclusion: don't install symfony/console 6.4.0；Found conflicting requirements 则明确列出谁和谁打架，例如：package-a requires symfony/console ^5.4 但 package-b requires symfony/console ^6.2。这两段合起来，基本就能定位冲突源头是哪个包、哪条约束。

• 如果 Conclusion 提到某个扩展（如 ext-intl），立刻运行 php -m 确认是否加载
• 如果出现 Root requirements 里写的是 "laravel/framework": "^11.0"，但报错说 monolog/monolog 3.0.0 requires php >=8.1，说明你本地 PHP 版本低于 8.1
• 注意 conflict 字段可能藏在你要装的包自己的 composer.json 里，不是你项目里写的才叫约束

用 composer why-not 快速验证假设

你想加 guzzlehttp/guzzle:^7.8 却失败？直接跑：composer why-not guzzlehttp/guzzle:^7.8。输出会按依赖链逐层列出所有拦路条件，比如：myapp/myproject dev-main requires php (^8.2)，而 some/sdk v3.1.0 requires php (^7.4) —— 这时你就知道问题不在 Guzzle，而在 some/sdk 和你的 PHP 版本不兼容。

• 输出里若含 ext-gd 或 ext-xml，就不是版本问题，是缺扩展
• 如果命令报 Command "why-not" is not defined，说明 Composer 版本太老，升级到 2.5+ 再试
• 这个命令不改任何文件，安全，建议每次 require 失败后第一反应就是它

别跳过 --dry-run -v 直接上 update

执行 composer update --dry-run -v 不会动 vendor 或 lock，但会完整走一遍依赖解析流程，并把第一个失败点打出来，比如：Cannot resolve package x at version y: constraint z conflicts with a1/b2。这比等整个 update 卡住再看报错快得多。

• 尤其当项目已有 composer.lock，优先用 composer install 而非 update —— 前者只还原，后者要重算，内存和时间成本都高得多
• 如果 --dry-run 也失败，说明约束矛盾已存在，不是新引入的问题，该回头检查最近改过的 composer.json 或第三方包更新
• 加 -v 后能看到具体哪个包在尝试安装哪一版时被拒绝，比 -vvv 更聚焦，信息量足够定位

留意那些不报错却静默失败的情况

有些失败根本不会抛出明显错误，比如 PHP 缺 openssl 扩展，Composer 安装器直接退出并返回 Exit Code 1；或者 sys_get_temp_dir() 返回路径不可写，脚本中途静默终止。这类问题必须靠前置检查。

• 运行 php -m | grep -E "(openssl|curl|json)"，三者缺一不可
• 查真实加载的 php.ini：用 php --ini，别信 XAMPP 面板显示的路径
• 确认临时目录可写：php -r "echo sys_get_temp_dir();"，然后 ls -ld 看权限（Linux/macOS）或右键属性（Windows）
• 如果是在 Docker 或 CI 中失败，大概率是容器内没装 php-curl 或没给 /tmp 足够空间

真正难解的 require 失败，往往不是某一行配置写错了，而是多个间接依赖通过不同路径对同一个包提出了互斥要求——这时候 why-not 的输出层级和 --dry-run -v 的首次中断点，就是你唯一能抓住的锚点。