composer install 慢的本质是下载与解压 dist 包耗时，主因包括直连境外源、缓存未清、lock 文件残留旧 URL；加速须三步：配国内镜像、清缓存、删 vendor 与 lock 后用 --prefer-dist 重装。
Composer 本身没有“导出”操作，你实际想加速的是 composer install 或 composer update 中的依赖下载与解压环节——尤其是当 composer.lock 已存在、只需拉取 dist 包并写入 vendor/ 时。
为什么 composer install 慢得像在导出
很多人说“导出慢”，其实是 composer install 卡在 Downloading 或 Extracting 阶段。根本原因不是 Composer 在“导出”，而是它在：从远程拉 ZIP 包 → 校验 SHA256 → 解压到 vendor/。其中前两步最耗时，且极易被网络、缓存、配置错误拖垮。
- 默认直连
packagist.org+codeload.github.com，DNS 解析慢、TLS 握手失败、无 CDN - 本地缓存路径不稳定（如 CI 中用 tmpfs），导致每次都是“冷下载”
-
composer.lock里记录的dist.url仍是github.com域名，换镜像源也无效 - PHP 内存不足或启用了 xdebug，让解压和 autoload 生成变慢数倍
composer install 加速必须做的三件事
别碰插件、别调并发参数——先确保基础链路干净高效：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 执行
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/（注意：repo.packagist是单数，composer是 type 值，URL 末尾必须带/） - 立刻运行
composer clear-cache，否则旧缓存会继续触发对packagist.org的校验请求 - 删掉项目里的
vendor/和composer.lock，再跑composer install --no-dev --prefer-dist（--prefer-dist强制走 ZIP，不走 Git clone）
http-max-concurrent-downloads 设置多少才有效
这个参数控制同时下载的 ZIP 包数量，但只在元数据已解析完毕、真正开始下载 dist 阶段起作用。设太高反而容易触发限流或连接重置。
- 推荐值是
8或10：composer config -g http-max-concurrent-downloads 10 -
parallel-downloads已废弃，设了也不生效，别用 - 如果网络本身抖动严重（比如企业内网出口带宽窄），反而建议设为
4，避免大量并发失败后重试 - 该参数对
Resolving dependencies阶段完全无效——那阶段纯 CPU + 内存计算，跟网络无关
最容易被忽略的两个硬伤
90% 的“加速失败”案例，都栽在这两个点上：
-
composer.lock文件没更新源信息：即使你全局换了镜像，只要 lock 文件里dist.url还是https://codeload.github.com/...，Composer 就一定绕过镜像直连 GitHub——必须删 lock 重装，或手动改 lock（不推荐） - CI 环境中缓存了旧
~/.composer/cache：这个缓存目录如果来自另一套镜像配置，会静默污染当前构建；建议在 CI 脚本开头加rm -rf ~/.composer/cache和rm composer.lock vendor/
