-vvv是唯一能暴露composer安装真实失败原因的开关，它透出http响应体、sat求解步骤、插件崩溃行和子进程stderr；而-v/-vv仅显示“正在加载仓库”或“404”等表层信息，无法揭示sat回溯风暴、gzip响应篡改或扩展缺失等卡点。
-vvv 是唯一能暴露 Composer 安装真实失败原因的开关，不是“多打点日志”，而是直接透出 HTTP 响应体、SAT 求解步骤、插件崩溃行和子进程 stderr。
为什么 -v 和 -vv 根本查不到安装卡点
它们只显示表层动作：-v 说“正在加载仓库”，-vv 可能报个 “404 Not Found”，但真正卡死的地方——比如 SAT 求解器陷入回溯风暴、gzip 响应被代理截断、ext-redis 在 config.platform 里写了却没装——全都不出现。日志停在 Resolving dependencies through SAT 后无下文？那不是网络问题，是约束逻辑卡死；出现 zlib_decode(): data error？说明压缩流被中间件篡改，得查防火墙或镜像源配置。
加了 -vvv 却只看到几行就卡住或空白
这不是命令写错，而是被环境干扰静默屏蔽：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
COMPOSER_DISABLE_XDEBUG=1必须加：Xdebug 默认会覆盖原始堆栈，尤其 IDE 自动注入时 -
COMPOSER_MEMORY_LIMIT=-1强制不限内存：大项目依赖解析可能 OOM，导致日志中途截断 -
--no-cache临时绕过缓存：旧缓存会让 -vvv 输出陈旧的求解路径，掩盖真实冲突点
必须重定向 stderr 才能捕获关键信息
Composer 把所有 -vvv 输出都扔进 stderr，而 grep 默认只读 stdout。不重定向，grep 就等于在空字符串里找东西：
-
composer install -vvv 2>&1 | grep "mirrors.aliyun.com"—— 定位下载失败包 -
composer update -vvv 2>&1 | grep "monolog" | head -n 20—— 看脚本执行顺序 -
composer install -vvv --no-ansi 2>&1 > debug.log—— CI 或 Docker 环境必备，避免 ANSI 控制符污染日志
别翻 ~/.composer/log，它根本不存运行时日志
Ubuntu/Debian 下的 ~/.composer/log（或 CentOS 的 ~/.composer/logs/composer.log）只记录极少量初始化错误，比如 config 加载失败或代理配置异常。它**完全不包含** install 或 update 过程中的任何依赖解析、HTTP 请求、脚本执行日志。你翻它，就是在翻一个低频故障快照。真正有用的日志只能靠命令行实时捕获：composer update -vvv 2>&1 | tee debug.log 是最可靠方式——终端可见 + 文件可存盘。进度条和调试日志混在一起时，--no-progress 可临时关闭进度覆盖式输出，让关键文本更清晰。
