Composer安装失败应优先用-vvv查看完整debug日志，定位具体报错行、缺失扩展或禁用命令；典型问题包括allow_url_fopen未启用、OpenSSL扩展缺失、DNS污染导致超时、composer.lock硬编码旧源及Warning级模块加载冲突。
直接看日志，90%的 Composer 安装失败问题都能定位到根因——不是网络、不是权限、更不是“玄学”，而是具体哪一行报错、哪个扩展没启用、哪条命令被禁用了。
如何开启 Composer 的 debug 日志
Composer 的 -vvv（三重 verbose）是唯一可靠的调试入口，它会打印出完整的 HTTP 请求、PHP 扩展检查、脚本执行链和依赖解析过程。普通 -v 或 -vv 往往漏掉关键细节。
- 安装阶段出错：用
curl -sS https://getcomposer.org/installer | php -vvv（注意php -vvv要加在管道末尾） - 依赖安装卡住/失败：运行
composer install -vvv或composer require vendor/package -vvv - 若提示
Could not open input file: composer-setup.php，说明当前目录根本没有该文件——别跳步，先确认curl是否真的下载成功（可用ls -l composer-*.php检查）
典型错误日志对照表（直接搜关键词）
遇到报错别慌，先 Ctrl+F 找下面这些高频字符串：
-
allow_url_fopen must be enabled→ PHP 配置项allow_url_fopen=Off，编辑php.ini改为On，然后php --ini确认生效路径 -
OpenSSL extension is required→ 缺 OpenSSL 扩展，CentOS/AlmaLinux 运行sudo yum install php-opcache php-openssl；Ubuntu/Debian 用sudo apt install php-openssl -
failed to open stream: Connection timed out→ 不是“网络不行”，而是 Packagist 域名被 DNS 污染或代理未生效。优先试curl -I https://packagist.org/packages.json，再设置export https_proxy=http://127.0.0.1:8080 -
post-install-cmd script failed→ 不是 Composer 本身坏了，是某个包的脚本执行失败。加--no-scripts快速绕过：composer install --no-scripts -vvv，再单独排查scripts字段里的命令（比如artisan clear-compiled在 Laravel 9+ 已废弃）
为什么改了镜像源还是走 GitHub？
日志里反复出现 https://api.github.com 或 codeload.github.com，但你明明执行了 composer config -g repo.packagist https://mirrors.aliyun.com/composer/？大概率是 composer.lock 在“硬编码”旧源地址。
-
composer.lock文件一旦存在，Composer 就会严格按它记录的 dist URL 下载，完全忽略全局镜像配置 - 临时解法：删掉
composer.lock，再跑composer install -vvv，观察日志是否变成https://mirrors.aliyun.com/composer/dists/... - 长期解法：团队统一用
composer update --lock更新 lock 文件，而非手动修改
真正难排查的，从来不是“找不到命令”，而是日志里一闪而过的 Warning: Module 'xxx' is already loaded 或 Failed loading /path/to/xdebug.so ——它们不会中断安装，但会让后续 post-xxx-cmd 脚本静默失败。所以，-vvv 不只是看报错，更要扫一遍所有 Warning 行。
