如何通过Composer命令分析项目中每个依赖包的实际下载耗时-composer-PHP中文网

composer 默认不显示单个包下载耗时；可通过 --profile 查看各阶段总耗时，清缓存后用 curl -w 测真实 url 下载时间，或自定义 zipdownloader 打点计时。

如何通过composer命令分析项目中每个依赖包的实际下载耗时

composer install 时怎么看到每个包的下载耗时

Composer 默认不暴露单个包的下载耗时，composer install 或 composer update 的进度条只显示整体百分比和当前包名，没有毫秒级计时。真要分析耗时，得绕过默认行为，用更底层的方式捕获网络请求时间。

最直接可行的办法是启用 Composer 的调试日志 + 手动加时序钩子，或者改用 curl 级别抓包。但注意：Composer 2.x 后内置了并行下载和缓存机制，很多包根本不会“下载”——而是从本地 vendor/composer/archives/ 或 ~/.composer/cache/ 解压，这类操作不走网络，也不计入“下载耗时”。所以先确认你关心的是「首次安装时的原始下载」还是「冷缓存下的真实网络耗时」。

用 COMPOSER_MEMORY_LIMIT 和 --profile 看整体耗时分布

--profile 是 Composer 自带的轻量级性能分析开关，它不会细分到每个包的下载阶段，但能告诉你哪些环节最拖沓：

composer install --profile 会输出总耗时、各阶段（resolving, downloading, installing）的耗时，以及内存峰值
如果 downloading 阶段明显偏长，说明网络或镜像源有问题；如果 installing 更久，那可能是解压、symlink 或脚本执行慢
搭配 COMPOSER_MEMORY_LIMIT=-1 可排除内存不足导致的反复 GC 干扰计时

强制跳过缓存，用 strace 或 curl 拦截真实 HTTP 请求

想拿到每个包 ZIP 的真实下载耗时，必须让 Composer 真正发起 HTTP 请求，并记录起止时间。推荐在 Linux/macOS 下用 strace（Linux）或 dtruss（macOS）跟踪 PHP 的 connect/recv 系统调用，但更简单的是重写 Composer 的下载器逻辑——不过这太重。实际更高效的做法是：

Discussion Composer

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

下载

清空缓存：composer clear-cache
禁用本地归档：composer config -g archive-format ''（防止走 vendor/composer/archives/）
用 curl -w '\nTTFB: %{time_starttransfer}, Total: %{time_total}\n' -o /dev/null -sS https://repo.packagist.org/files/xxx.zip 手动测几个关键包的 URL（URL 可从 composer show -t 或 composer install -vvv 日志里扒）
注意 Packagist 的 ZIP URL 是动态生成的，且带签名，不能直接构造；稳妥方式是先跑一次 composer install -vvv，从输出中 grep Downloading 行，提取出完整 URL 再用 curl 测

自定义 Downloader 类记录时间戳（适合深度分析）

如果你需要长期监控或集成进 CI，可以继承 Composer 的 ZipDownloader，重写 download() 方法，在 file_get_contents() 或 cURL 调用前后打点：

protected function download(PackageInterface $package, $path, $url)
{
    $start = microtime(true);
    $result = parent::download($package, $path, $url);
    $duration = microtime(true) - $start;
    file_put_contents('download-timings.log', sprintf("%s\t%s\t%.3f\n", $package->getName(), $url, $duration), FILE_APPEND);
    return $result;
}

这要求你把自定义类注册进 Composer 的 IO 和 downloader 体系，需修改 composer.json 的 autoload-dev 并在项目根目录写一个简易插件——不是一行命令能搞定的事。而且要注意：Composer 2.2+ 对 downloader 的扩展支持变严格，create-project 场景下可能不生效。

真正容易被忽略的一点是：Packagist 官方源已默认启用 HTTP/2 和 CDN，但国内用户常配镜像（如阿里云、腾讯云），这些镜像的 ZIP 文件可能没做分片或压缩优化，导致大包（比如 laravel/framework）解压比下载还慢——这时候你盯着“下载耗时”反而会误判瓶颈。