只有-vvv（三个v）才真正开启Composer调试模式，可查看SAT求解器步骤、HTTP原始响应、插件异常堆栈及platform配置真实缺失原因；-v和-vv仅显示有限信息。
用 -vvv 才算真正开启 Composer 调试模式
不是加 -v 或 -vv，只有 -vvv（三个 v）才能打开底层调试通道，看到依赖求解器（SAT solver）每一步尝试、HTTP 请求原始响应、插件异常堆栈、甚至 ext-foobar 在 config.platform 里写了但没装的真实原因。
常见错误现象：执行 composer update 报错 “Your requirements could not be resolved”，但提示只说“because”，没说具体哪一行约束卡住；或者日志末尾突然中断，看不到堆栈。
-
-v：只显示下载进度、包名和版本号 -
-vv：多一点匹配逻辑，比如“Trying laravel/framework[10.0.0]” -
-vvv：才输出 curl 请求头、未解压的 JSON 响应体、solver 回溯路径、插件抛出的完整Exception trace
终端刷屏太快？必须重定向保存日志
关键错误常在滚动中一闪而过，尤其当网络慢或依赖多时。composer install -vvv 直接回车，等于白跑。
实操建议：
- 最可靠方式：
composer update -vvv 2>&1 | tee debug.log—— 实时看 + 持久存盘 - CI 环境下加
--no-ansi避免控制字符污染日志：composer install -vvv --no-ansi > debug.log 2>&1 - 别盲目堆
-vvv：先用--profile看耗时分布，确认是“解析慢”还是“下载卡”，再针对性加-vvv
Xdebug 和内存限制会悄悄破坏 -vvv 日志
很多同学加了 -vvv 却看不到完整堆栈，不是命令不对，而是被环境干扰了。
典型干扰源：
-
Xdebug：默认会截断或覆盖原始异常堆栈，尤其在 IDE 自动注入时。解决方法是加环境变量：COMPOSER_DISABLE_XDEBUG=1 composer install -vvv - 内存不足：Composer 解析大项目时可能 OOM，导致日志中途截断。加
COMPOSER_MEMORY_LIMIT=-1强制不限制 - 缓存污染：旧缓存可能让
-vvv输出陈旧决策路径。可临时加--no-cache排查：composer update --no-cache -vvv
定位冲突别只盯日志，配合 composer prohibits 和环境变量
-vvv 日志动辄上千行，“因为 A 依赖 B，B 要求 C，C 不兼容 D” 这种链条靠肉眼扫效率极低。
更高效的做法是组合使用：
- 快速锁定冲突包：
composer prohibits vendor/package:3.0，直接告诉你谁在阻止这个版本 - 让求解器“开口说话”：
COMPOSER_VERBOSE_SOLVER=1 composer update -vv（注意这里-vv就够，COMPOSER_VERBOSE_SOLVER已接管细节） - 检查平台配置是否造假：
composer config platform，确认php、ext-*版本是否真在系统里存在
真正难的不是看到日志，而是从几百行 solver 回溯里识别出那个“唯一不兼容的约束”。这时候 prohibits 比 -vvv 更快，也更准。
