Composer 默认不显示单个包下载耗时；可通过 --profile 查看各阶段总耗时，清缓存后用 curl -w 测真实 URL 下载时间，或自定义 ZipDownloader 打点计时。
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 的下载器逻辑——不过这太重。实际更高效的做法是：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 清空缓存：
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，从输出中 grepDownloading行，提取出完整 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）解压比下载还慢——这时候你盯着“下载耗时”反而会误判瓶颈。
