composer 默认不使用 bzip2，依赖下载和解压全程基于 zlib（gzip）或 zip 扩展，不支持 .bz2；手动干预收益有限且风险明确，真正瓶颈在于 http 协议、ssl 配置、缓存策略及 dev 包冗余。
Composer 默认不用 bzip2，它打包的 .phar 或安装包走的是 gzip（zlib）路径；想靠 bzip2 提升大体积包吞吐，得绕过默认流程手动干预，而且收益有限、风险明确。
Composer install 时根本没用 bzip2
Composer 的依赖下载和解压全程由 composer install 调用内部 downloader（如 ZipDownloader 或 ArchiveDownloader）完成。这些组件底层依赖 PHP 的 zlib 扩展（对应 gzip）或 zip 扩展，不调用 bzip2 扩展，也不生成 .bz2 文件。即使你本地装了 bzip2 命令或启用了 bz2 PHP 扩展，Composer 也不会自动切换压缩后端。
- 验证方式：运行
composer install -vvv，观察日志里出现的解压命令——全是unzip或gzopen()，绝不会出现bzopen()或bzip2 -d - 原因很直接：PHP 的
ZipArchive类不支持 .bz2；而 Composer 的 archive 下载逻辑只认.zip和.tar.gz，根本不处理.tar.bz2 - 如果你看到某个包带
.tar.bz2后缀，那基本是第三方私有仓库自己提供的归档，Composer 只是把它当普通二进制下载下来，后续解压会失败——除非你重写 downloader
强行用 bzip2 压缩 vendor 目录反而拖慢整体吞吐
有人试过先 tar -cjf vendor.tar.bz2 vendor/ 再上传到私有镜像，以为能减小传输体积、加速拉取。结果往往适得其反：
-
bzip2压缩阶段 CPU 占用高、耗时长，尤其在 CI 环境多并发构建时，容易卡住整个 pipeline - 解压时无法流式进行：
tar -xjf必须读完整个.bz2流才能开始提取，而tar -xzf支持边解压边写文件，实际感知更快 - PHP 进程内解压
.bz2需要bzdecompress()或临时调用系统bzip2命令，前者内存开销大（bzip2 解压峰值内存可达压缩后体积的 3–4 倍），后者引入 shell 调用开销和安全风险 - 实测对比：一个 120MB 的
vendor/目录，gzip 压缩耗时约 8s，bzip2 耗时 32s；网络传输节省约 9MB，但总时间（压缩+上传+下载+解压）反而多出 15–20s
真正影响 Composer 吞吐的关键点不在压缩算法
瓶颈从来不是“用 gzip 还是 bzip2”，而是更底层的 IO 和协议层行为：
- HTTP/1.1 没有并发连接复用，大量小包请求堆积；升级到 HTTP/2（需服务端支持）可显著减少首字节延迟
- 未启用
composer config -g repo.packagist.org.allow_ssl_downloads true导致 SSL 握手反复失败，重试放大延迟 - 私有仓库没配 ETag 或 Last-Modified，每次
composer update都全量下载，哪怕内容没变 - vendor 目录里混入大量 dev-only 包（如
phpunit），却在生产环境也拉下来——用--no-dev可立竿见影减小体积和时间
想优化大体积包吞吐，与其折腾 bzip2，不如检查镜像源响应头是否带 Content-Encoding: gzip、确认 PHP 的 zlib.output_compression 是否关闭（避免双重压缩）、以及把 vendor 归档拆成按组件粒度缓存——这些地方的收益远超换压缩算法。
