Composer安装慢的根本原因是默认串行下载+国内直连packagist.org失效+本地autoload生成开销大；需换镜像源、启用parallel-downloads=10~15、CI中加--no-autoloader--no-scripts--no-dev--prefer-dist三步到位，实测提速3–5倍。
Composer 安装慢，不是网络差，而是默认串行下载 + 国内直连 packagist.org 失效 + 本地 autoload 生成开销大这三者叠加。换镜像源、开并行、跳过非必要步骤，三步到位才能实测提速 3–5 倍。
怎么确认并行下载已启用且设对了并发数
Composer 2.2+ 默认支持 parallel-downloads，但默认值是 3，等于没开。不检查就调参数，容易白忙活。
- 查当前值：
composer config -g parallel-downloads，输出应为10或15（别超20） - 设全局并发：
composer config -g parallel-downloads 15 - 注意：该配置只对
composer install有效；update因依赖图重算逻辑仍部分串行 - 若报
file_put_contents(/tmp/): failed to open stream，说明并发过高触发临时文件竞争，降到8或6再试
为什么换镜像源后还是卡在 downloading
换源只是第一步，但 DNS 缓存、镜像限流、HTTPS 握手失败都会让并发请求堵在连接层，看起来仍是“卡住”。
- 必须清缓存：
composer clear-cache，否则旧包可能仍走原源 - 推荐阿里云或清华源：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 某些企业网络会复用 cURL 的 DNS 缓存，导致镜像域名解析仍走海外节点；可加环境变量绕过：
export COMPOSER_NO_INTERACTION=1 - 如果卡在某个特定包（如
symfony/console），用strace -e trace=connect,write -p $(pgrep -f "composer install")看是否反复重试 TLS 握手
CI 构建中哪些参数组合能省掉 30%+ 时间
开发机要 autoload 和脚本，但 CI 场景下它们全是冗余开销。不关掉，vendor 目录装完也跑不起来——因为根本没生成 autoload.php。
- 必加：
--no-autoloader --no-scripts --no-dev --prefer-dist -
--no-autoloader跳过生成vendor/autoload.php，后续用composer dump-autoload --optimize单独补 -
--no-scripts阻止执行post-install-cmd，避免意外触发npm install或php artisan optimize -
--prefer-dist强制走压缩包而非 Git 克隆，快且解压轻量；它和parallel-downloads是咬合生效的 - 注意：
--classmap-authoritative只应在 CI 中启用，开发时开了会导致新增类不被识别
vendor 目录写入慢？那不是网络问题
并行下载快了，但 vendor 解压后写文件又卡住，常见于 macOS APFS 或 Windows 启用实时杀毒软件的环境。每写一个文件都触发 fsync，I/O 吞吐直接从 120MB/s 掉到 8MB/s。
- 关掉 Windows Defender 实时扫描或腾讯电脑管家的“文件系统防护”
- Docker 构建中，在
docker run或Dockerfile中加--security-opt seccomp=unconfined（仅限可信环境）可绕过部分 fsync 限制 - 不要盲目调高
memory_limit或COMPOSER_PROCESS_TIMEOUT，它们解决不了 I/O 瓶颈 - 如果项目含大量小包（如 Laravel + 100+ 依赖），建议把
composer install和dump-autoload拆成两步，避免单次进程扛全量 I/O
