Composer 安装速度一直很慢？国内镜像源切换与多线程提效方案-composer-PHP中文网

composer安装慢主因非网络，而是镜像未生效、缓存未清、parallel-downloads未启用或设太低；需验证config输出为含正确url的json、设parallel-downloads=10、删prefer-source、清缓存并确认下载域名。

composer 安装速度一直很慢？国内镜像源切换与多线程提效方案

Composer 安装慢，90% 以上不是你网差，而是镜像没切成功、缓存没清、parallel-downloads 没开或设太低。 开完这三项（composer config -g repo.packagist + composer clear-cache + composer config -g parallel-downloads 10），多数项目从 3–5 分钟压到 30 秒内；但若跳过验证或忽略私有包硬编码 GitHub URL，反而会卡在 GithubRateLimitException 或 fallback 到慢速 git clone。

怎么确认国内镜像源真的生效了

很多人执行了 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 就以为搞定了，其实可能被项目级 composer.json 里的 repositories 覆盖，或者旧缓存还在拉 packagist.org 的元数据。

运行 composer config -g repo.packagist，输出里必须明确含 "url": "https://mirrors.aliyun.com/composer/" —— 不是 https://packagist.org，也不是空值
再跑一次 composer clear-cache，否则 Composer 可能继续用本地缓存的海外索引去“找包”，根本没走镜像
临时绕过所有自定义源验证：执行 composer install --no-plugins --repository=https://packagist.org，如果变快，说明你本地配置的镜像或 repositories 有问题
注意：https://packagist.phpcomposer.com 已停更，返回 404 是常态，别用

parallel-downloads 设多少才真提速

parallel-downloads 是 Composer 2.2+ 原生并发机制，不是插件，也不是“多线程”——它让多个 dist ZIP 包同时下载。但它只对 composer install 有效，composer update 仍要串行算依赖图。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

默认值是 3，基本等于没开；推荐设为 10：composer config -g parallel-downloads 10
别盲目冲到 20：某些企业网络或低配 CI 环境会出现 file_put_contents(): failed to open stream（临时文件竞争），降到 6–8 更稳
这个参数依赖镜像源支持 HTTP/2 多路复用，阿里云、清华、腾讯镜像都支持；但如果你的私有源不支持，设高了也白搭
运行 composer --version 确认是 2.2+；如果是 1.x，先 composer self-update

为什么加了 --prefer-dist 还是卡在 downloading

--prefer-dist 的作用是优先下 ZIP 包，而非 git clone 源码。但它有个关键前提：镜像必须已生效。国内镜像（如阿里云）几乎不缓存 source，只缓存 dist —— 镜像没切成功，--prefer-dist 就会 fallback 到慢速 Git 克隆，甚至直接失败。

检查项目 composer.json 是否有 "config": {"prefer-source": true}，它会覆盖全局 prefer-dist，必须手动删掉
某些包硬编码了 GitHub URL，比如 "dist": {"url": "https://github.com/xxx/yyy/archive/"}，这种完全绕过镜像，会撞上 GitHub 的 403 rate limit
遇到 GithubRateLimitException，要么配 GitHub Token：composer config -g github-oauth.github.com your_token_here，要么把这类包 fork 到 Gitee 并改 dist.url
--prefer-dist 在 CI 场景下建议配合 --no-autoloader --no-scripts，省掉 autoload 生成和钩子执行，可再减 30% 时间

容易被忽略的隐性卡点

真正拖慢安装的，往往不是下载本身，而是 lock 文件校验、autoload 重建、以及没关掉的 post-install-cmd 脚本。尤其在 CI 构建时，反复执行前端构建或缓存清理，会让耗时翻倍。

确保 composer.lock 已提交到 Git —— 否则每次都要重新解析全部依赖，卡在 Resolving dependencies
检查 PHP CLI 是否启用了 OPcache：php -d opcache.enable_cli=1 composer install，某些 Docker 镜像默认关掉它，导致 Composer 自身代码反复编译
私有源若不支持 providers-url 和 provider-includes，Composer 会下载全量元数据，哪怕只装一个包也要拉几 MB JSON
composer install 默认会生成 autoload，CI 中可用 --no-autoloader 跳过，后续用 composer dump-autoload --optimize 单独处理