Composer网络代理下载进度监听-composer-PHP中文网

composer不读http_proxy环境变量，只认配置文件中的http-proxy和https-proxy字段，且必须同时配置；https-proxy值须以http://开头，密码需url编码。

composer网络代理下载进度监听

为什么`HTTP_PROXY`环境变量对`composer install`完全无效

Composer 不读系统级的 HTTP_PROXY 或 HTTPS_PROXY 环境变量，这是它和大多数 CLI 工具的根本区别。你设了环境变量却没效果，不是网络问题，是 Composer 根本不看——它只认自己配置文件里的 http-proxy 和 https-proxy 两个字段，且必须同时存在。

常见错误现象包括：Loading composer repositories 卡住、cURL error 35（SSL connect error）、Failed to decode response。这些都不是代理没启动，而是 Composer 在发 HTTPS 请求时发现没配 https-proxy，就直接 fallback 到直连，结果被公司防火墙或 TLS 中间设备拦截。

http-proxy 只处理纯 HTTP 请求（极少用），对 https://packagist.org 这类地址完全无感
https-proxy 的值必须是 http:// 开头，哪怕你的代理监听在 https://127.0.0.1:8443 —— Composer 强制要求用 HTTP 协议建 CONNECT 隧道
密码含 @、/、: 必须 URL 编码，例如 pa@ss/word → pa%40ss%2Fword

如何确认代理已生效并监听到真实下载请求

光配完不验证，等于没配。Composer 没有“代理测试”命令，只能靠日志反推是否真走代理路径。

执行以下命令组合，过滤出所有下载行为：

composer install -vvv 2>&1 | grep "Downloading"

如果代理生效，你会看到类似这样的输出：

Downloading https://mirrors.aliyun.com/composer/provider-laravel~framework.json

注意：域名必须是你镜像源的地址，而不是 packagist.org 或 codeload.github.com；如果混着出现，说明部分包绕过了代理（比如私有仓库硬编码了 dist URL）。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

必须加 2>&1，否则 Windows PowerShell 或某些 CI 环境会丢掉 stderr 日志，看不到 Downloading 行
若日志里全是 packagist.org，说明镜像源没切成功，代理再对也白搭
并发下载时，多条 Downloading 行应在 1 秒内密集刷出；如果单行滚动、间隔长，大概率是代理链路卡在 TLS 握手或 DNS 解析

`pre-file-download`事件才是真正的下载进度钩子

HTTP_PROXY 或镜像源只能控制“往哪下”，但无法告诉你“正在下什么”“下了多少”。要实现实时下载进度监听，唯一可靠方式是监听 pre-file-download 事件——它在每次 ZIP/TAR 包发起 HTTP 请求前触发，你可以注入自定义逻辑记录 URL、起始时间、甚至修改 RemoteFilesystem 实例的底层 cURL 句柄。

典型用法是在插件中注册监听器，例如：

public function activate(Composer $composer, IOInterface $io)
{
    $dispatcher = $composer->getEventDispatcher();
    $dispatcher->addListener('pre-file-download', [$this, 'onPreFileDownload']);
}

public function onPreFileDownload(FileDownloaderEvent $event)
{
    $url = $event->getProcessedUrl();
    $io->write("→ Downloading: <info>{$url}</info>");
}

该事件不干预元数据（packages.json）获取，只作用于 dist 文件（ZIP/TAR）和 provider JSON 下载
不能用 composer.json 的 scripts 注册，必须写成 Composer 插件（class + autoload + extra 声明）
如果你只是想打日志，别碰 $event->getRemoteFilesystem()；想改请求头（如加 Authorization）才需要调用 setOptions()

代理+镜像混用时最容易被忽略的瓶颈点

很多人以为“配了代理 + 切了镜像 = 稳了”，其实最常卡死的地方根本不在网络层：TLS 握手耗时、provider JSON 下载吞吐、以及 ZIP 包首字节延迟（time_starttransfer）这三个指标比总耗时更有诊断价值。

用 curl 单独测，比等 composer install 跑完更准：

测元数据首字节：curl -o /dev/null -s -w "%{time_starttransfer}\n" https://mirrors.aliyun.com/composer/packages.json，超 1.5s 的镜像直接排除（说明反向代理或 CDN 节点有问题）
测 ZIP 吞吐：curl -r 0-1048575 -o /dev/null -s -w "%{speed_download}\n" https://mirrors.tuna.tsinghua.edu.cn/composer/provider-laravel~framework.json，低于 1MB/s 容易成为高依赖项目的瓶颈
代理本身不加速，只解决“能不能通”；真正提速靠的是镜像源的地理就近 + CDN 覆盖，不是代理转发

代理链路一旦引入，排查维度就从“源是否可用”变成“DNS → 代理连接 → TLS 握手 → 镜像响应 → 下载带宽”五层嵌套，少一层验证都可能白忙活半天。