-vvv是Composer唯一全局生效的调试标志，输出HTTP请求、依赖解析、锁文件比对等完整细节；-v/-vv仅提升日志级别，无法暴露决策链；排错须用composer install/update -vvv并重定向日志，脚本错误需单独执行定位。
Composer命令加-vvv开启完整调试输出
Composer本身没有“开启调试脚本”的开关，所有调试能力都通过命令行参数触发。-vvv是唯一可靠、全局生效的调试标志，它会输出HTTP请求细节、包解析过程、依赖回溯路径、锁文件比对差异，甚至PHP扩展检测结果。
常见误操作是只加-v或-vv——它们只提升日志级别，不显示关键决策链。只有-vvv能暴露Composer内部如何选择版本、为什么跳过某个仓库、在哪一步解析失败。
实操建议：
- 所有排错场景统一用
composer install -vvv或composer update -vvv，别省略第三个v - 如果命令卡住，
-vvv输出最后几行往往就是阻塞点（比如某HTTP GET超时、某git clone权限拒绝） - 输出太长？用
composer update -vvv 2>&1 | grep -A5 -B5 "error|failed|skipping"快速定位关键词
Composer日志默认不落盘，需手动重定向到文件
Composer不会自动写日志文件，-vvv输出直接刷到终端。一旦滚动消失或终端关闭，信息就丢了。这不是Bug，是设计使然——它假设你正在交互式排错。
要保留完整上下文，必须显式重定向：
- Linux/macOS：
composer update -vvv 2>&1 > composer-debug.log（注意2>&1确保错误流也进文件） - Windows PowerShell：
composer update -vvv 2>&1 | Out-File composer-debug.log -Encoding UTF8 - 别用
>>追加，多次运行会混叠；每次排错前先rm composer-debug.log或清空
文件里会包含真实执行的git命令、curl请求头、JSON API响应片段——这些是判断网络问题或私有仓库配置错误的核心依据。
常见-vvv输出中必须盯住的三类线索
翻几百行-vvv日志容易迷失。重点关注以下三处，90%的依赖问题都能定位：
-
“Reading
composer.jsonfrom”之后是否加载了你预期的项目根目录？如果路径不对（比如进了子模块），后续所有解析都错 -
“Executing command (CWD: …)”下面跟着的
git或hg命令是否报Permission denied或Could not resolve host？这直接对应私有仓库SSH密钥缺失或DNS故障 -
“Resolving dependencies through SAT”块结束后，如果有
Root package requires ... but it is not satisfiable，说明约束冲突，此时往上翻看“Found package … with version …”那段，对比你require的版本和实际找到的版本范围
Composer插件或脚本失败时，-vvv不显示PHP错误堆栈
如果你在composer.json里定义了scripts（如"post-install-cmd": "My\Script::run"），而脚本抛出异常，-vvv只会显示“Script … handling … returned with error code 255”，不会打印Fatal error详情。
这时必须手动触发脚本并加PHP调试参数：
- 先查脚本注册名：
composer run-script --list - 再单独执行并显示错误：
php -d display_errors=1 -d error_reporting=-1 vendor/autoload.php -r "MyScript::run();" - 如果脚本依赖Composer对象，改用
vendor/bin/composer run-script your-script-name -vvv——部分插件会在该模式下透出底层异常
很多“Composer安装成功但脚本不执行”的问题，根源其实是脚本里用了PHP 8.2特性，而当前环境是PHP 7.4，-vvv完全不提示，必须单独跑才能看到ParseError。
