Composer报错日志默认存于~/.composer/logs/，按日期命名（如2026-10-20_14-22-35.log），记录完整stderr和环境变量；空日志多因权限问题，407错误指向NTLM代理未中转，卡住时需用composer install -vvv暴露真实错误。
报错日志在哪？先看 ~/.composer/logs/
Composer 默认把每次命令的完整 stderr 和环境变量记在 ~/.composer/logs/ 里，文件按日期命名（如 2026-10-20_14-22-35.log）。它比终端输出更全，尤其当错误被静默吞掉时——比如只显示 Script failed 却没堆栈，日志里往往有 Fatal error: Uncaught Error: 或 cURL error 28 的原始行。
直接查最新日志：tail -n 50 ~/.composer/logs/*.log | grep -E "(error|ERROR|curl|timeout|407)"
- 如果日志为空，说明 Composer 没写入成功，大概率是权限问题：
ls -ld ~/.composer/logs看属主是否为当前用户 - 日志里出现
407 Proxy Authentication Required，基本锁定 NTLM 代理未中转 - 日志末尾有
Loading composer repositories后长时间停住，再无后续，大概率是https-proxy没配或格式非法
为什么 composer install 不报错却卡住？用 -vvv 强制透出底层错误
默认模式下 Composer 会吞掉子进程的 stderr，你只看到 Script xxx handling yyy returned with error code 1，但不知道哪行 PHP 崩了、curl 连的哪个地址、甚至是不是根本没走代理。
必须加 -vvv：composer install -vvv 2>&1 | head -n 200
- 你会看到每条实际执行的命令，例如：
Executing command (/path): /usr/bin/php ... script.php - 关键线索藏在环境变量段：
HTTP_PROXY=http://127.0.0.1:7890 HTTPS_PROXY=http://127.0.0.1:7890—— 如果这里只有HTTP_PROXY，HTTPS_PROXY缺失或值是https://...，就是硬性配置失败 - 若看到
curl_setopt(): Invalid curl configuration option，说明 proxy 地址含非法字符（如未 URL 编码的@或/）
代理配置本身有没有生效？用 composer config -g --list 验证
别信自己“记得配过”，直接查全局配置是否写进去了：
composer config -g --list | grep -E "(http|https)-proxy"
- 必须同时输出两行：
http-proxy和https-proxy；只有一行 = 配置不完整 -
https-proxy的值协议头必须是http://，哪怕你的代理监听的是 HTTPS 端口；写成https://127.0.0.1:7890或127.0.0.1:7890都会静默失效 - 带认证的密码含
@或/，必须 URL 编码：pa%40ss%2Fword，否则整个 proxy 字符串被截断
绕过代理快速验证是不是它的问题
临时清空代理环境变量，让 Composer 走直连：
HTTP_PROXY= HTTPS_PROXY= composer install -vvv
- 如果这时成功了，100% 是代理链路问题，不是包本身或权限问题
- 如果还是卡住或报错，问题在别处：PHP socket 超时、DNS 解析失败、或
default_socket_timeout设置过低（查php -i | grep default_socket_timeout） - 注意：这个测试要关掉所有 shell 级代理变量，包括
export http_proxy=...这类已设的变量，否则会被继承
真正难调的不是配错字段，而是 https-proxy 格式合法但代理服务本身不支持 CONNECT 隧道，或者公司防火墙拦截了隧道握手——这种情况下日志里只有空白等待，-vvv 也只显示 curl 初始化后就没了下文。
