加 -vvv 未见下载地址是因为 composer 在依赖解析失败等错误时会提前退出，根本不会执行下载；真正的下载链接是 p2/xxx.json 或 zipball/commit-hash 等路径，而非 packages.json。
composer install/update 为什么加 -vvv 还没看到下载地址
因为 -vvv 确实能显示下载行为，但前提是命令得真正走到“下载”阶段——如果依赖解析失败、平台配置不匹配或插件报错，Composer 会在日志开头就退出，根本不会打印任何 Downloading 行。
- 先运行
composer config --list | grep config.verbose，确认没有被全局配置设为false（这会直接屏蔽所有-v参数） - 检查
config.platform是否误写了不存在的扩展，比如"ext-imagick": "1.0"，这种错误在-vvv下会提前暴露并中断流程 - 如果卡在
Downloading https://repo.packagist.org/packages.json不动，大概率是网络问题，不是日志没开——-vvv已把 cURL debug 输出打出来，只是默认被 Composer 日志格式过滤了原始响应头
如何从 -vvv 输出里快速定位真实下载源
-vvv 日志里真正代表“包下载地址”的，不是 packages.json 那一行，而是后续出现的 p2/xxx~x.x.json 或 zipball/commit-hash 这类链接——它们才对应实际归档文件的来源。
- 执行
composer require monolog/monolog -vvv，盯住输出中含zipball或dist.url的行，例如：Downloading https://api.github.com/repos/Seldaek/monolog/zipball/7c48e4b59f63a852d45975691597560e0984779b - 如果看到的是
https://mirrors.aliyun.com/composer/开头的路径，说明你正在走镜像；若想验证原始源，先composer config --unset repos.packagist再重试 - 缓存目录名也藏了线索：
~/.composer/cache/repo/https---mirrors.aliyun.com-composer/中的 URL 就是上次实际请求的源
比 -vvv 更稳的调试组合：--profile + 环境变量
纯靠 -vvv 容易淹没关键信息，尤其当输出长达上千行时。真正排错时，更需要知道“慢在哪”和“内存够不够”，而不是看全量 HTTP 流水账。
- 加
--profile能清楚看到各阶段耗时，比如installing dependencies占了 92% 时间，那问题大概率出在解压或写磁盘，而非网络 - 设置
COMPOSER_MEMORY_LIMIT=-1防止因内存不足导致静默失败——-vvv本身日志量大，更容易触发 OOM - 用
COMPOSER_HTTP_PROXY=http://127.0.0.1:8888配合 Charles 抓包，比终端里翻日志直观得多，尤其能看清 302 重定向、gzip 响应体是否损坏
日志保存到文件的可靠写法
Composer 没有内置日志文件功能，但 shell 重定向足够可靠。注意必须同时捕获 stdout 和 stderr，否则错误信息会丢失。
- 最简写法：
composer update -vvv > composer.log 2>&1，2>&1表示把标准错误重定向到标准输出，再一起写入文件 - 想边看边存，用
tee：composer install -vvv 2>&1 | tee composer.log，终端实时滚动，文件同步落盘 - Windows PowerShell 下长日志容易被截断，建议改用
cmd，或加2>&1 | more分页查看
真正难的不是打开日志，而是读懂它——比如看到 Failed to decode response: zlib_decode(): data error，说明响应体 gzip 解压失败，这时该怀疑代理或镜像服务是否异常，而不是反复重试命令。
