Composer 2.1+ 默认启用并发下载，需确认版本≥2.1、切换国内镜像源（如阿里云）、设http-max-concurrent-downloads为8–10，并通过-vvv日志验证多包同时下载。
Composer 2.1+ 默认已启用并发下载，但多数人装了不生效、提速不明显，根本原因是版本没确认、镜像源没换、配置项写错，或者还在用已失效的 hirak/prestissimo。
怎么确认并行下载真在跑
别只看命令有没有加参数，关键看输出日志是否动态跳变：
- 执行
composer install -vvv，若看到多行Downloading https://...几乎同时出现，或进度条显示类似Downloading (7/42)并快速跳到(12/42)，说明并行已激活 - 如果始终单行打印、卡在某个包不动，大概率是镜像源响应慢或被限流，不是并发没开
- 运行
composer --version，输出必须是Composer version 2.1.x或更高；低于此版本（如1.10.22）压根不支持原生并行，parallel-downloads和http-max-concurrent-downloads都无效 -
composer diagnose中若仍提示hirak/prestissimo，说明插件残留，它会干扰新版调度逻辑
http-max-concurrent-downloads 和 parallel-downloads 到底该设哪个
Composer 2.2+ 只认 http-max-concurrent-downloads，另一个已被弃用——设了也白设，还可能误导自己。
- 查看当前值：
composer config -g http-max-concurrent-downloads，默认通常是6，不是3或0 - 合理上限是
8–10：设成20容易触发本地临时文件竞争，报file_put_contents(/tmp/): failed to open stream - 设完立刻验证：
composer config --global http-max-concurrent-downloads 10 - 注意：这个配置只对
composer install生效；composer update因需实时解析依赖图，底层仍有串行环节，别指望它快 3 倍
镜像源没换，调再高也没用
并发只是“同时发请求”，如果每个请求都卡在 DNS 解析或 TLS 握手，那开 10 个线程等于 10 个排队窗口。
- 全局换阿里云源（最稳）：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 换源后必须清缓存：
composer clear-cache，否则旧元数据仍尝试回源 - 验证是否生效：
composer config -g repo.packagist输出应为完整 URL，不是null或空值 - 别用已停更的源（如
packagist.phpcomposer.com），清华源地址已更新为https://mirrors.tuna.tsinghua.edu.cn/composer/ - 某些私有仓库或内网镜像不支持 HTTP/2 或
Range请求头，强行高并发反而返回416错误
CI/CD 中必须关掉的三件事
开发时需要 autoload、脚本、dev 包，但构建阶段它们全是拖慢主力。
- 禁用自动加载器生成：
--no-autoloader（后续用composer dump-autoload --optimize单独补） - 跳过所有脚本钩子：
--no-scripts，防止意外触发npm install或phpunit --dry-run - 跳过 dev 依赖：
--no-dev，省掉 30–60% 时间；搭配--prefer-dist强制走 ZIP 包，避免 Git clone - 组合使用示例：
composer install --no-dev --prefer-dist --no-autoloader --no-scripts --optimize-autoloader - 注意：
--classmap-authoritative在 CI 中安全，但在本地开发慎用——新增类会直接报错
真正卡住安装速度的，往往不是“并发数设多少”，而是“第一个包的 DNS 能不能秒回”“镜像站是不是正在同步延迟”“vendor 目录所在的磁盘是不是 NFS 挂载”。这些点比调参数更值得花时间验证。
