Composer命令报错但没提示具体原因
默认情况下，Composer只显示简短错误摘要，比如 Failed to download vendor/package 或 Dependency resolution failed，根本看不出是网络超时、权限问题、还是composer.json语法错误。这时候直接加 -vvv（三重详细模式）是最有效的一线排查手段——它会输出完整的HTTP请求头、JSON解析过程、依赖回溯路径和实际执行的系统命令。
为什么-vvv比--verbose或-v更管用
--verbose（或 -v）只展开部分日志，而 -vvv 是Composer唯一启用「全栈跟踪」的开关：它会打印出HttpClient底层的cURL调用、JsonParser逐字符解析失败的位置、甚至RepositoryManager尝试加载哪些源以及先后顺序。常见卡点如私有Git仓库认证失败、Packagist镜像返回了503但被静默吞掉、PHP扩展缺失导致json_decode()中途崩溃，这些都只有-vvv能暴露。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
执行-vvv后重点关注哪几类输出
拿到长日志别从头硬读，盯住这四块：
- 以
Reading ./composer.json开头的部分——确认是否真读到了你改过的文件，路径有没有软链接陷阱 - 包含
curl_setopt或GET https://repo.packagist.org/...的段落——看HTTP状态码和响应体，常见503 Service Temporarily Unavailable或空响应 - 出现
Parse error:或JSON decode error的行——往往指向vendor/composer/installed.json损坏或composer.lock里混入了非法UTF-8字符 - 末尾反复出现
Resolving dependencies through SAT后卡住——说明依赖冲突太复杂，需要配合composer prohibits定位具体包版本矛盾
不是所有问题都能靠-vvv解决
-vvv 能暴露“发生了什么”，但不解释“为什么发生”。比如看到 file_put_contents(/path/to/vendor/autoload.php): failed to open stream: Permission denied，日志清楚，但根源可能是Docker容器里UID不匹配，或是Windows上NTFS权限继承异常；再比如 curl error 60: SSL certificate problem，日志只报错，得手动配 composer config -g cafile /path/to/cert.pem 或关校验（不推荐）。这类情况要结合日志里的具体错误信息，再查对应环境的权限模型或TLS配置。
