composer安装慢主因非网络，而是配置错误：需同步启用--prefer-dist、切换国内镜像（如阿里云）、设置parallel-downloads=10；否则可能fallback至慢速source或并发失效。
Composer 安装慢，90% 以上不是网络问题，而是配置没对、命令用错、或者镜像没生效。 开 --prefer-dist、换国内镜像、启用并行下载这三步做完，多数项目安装耗时能从 3–5 分钟压到 30 秒内；但若跳过验证或忽略私有源兼容性，反而会报错中断。
为什么 composer install 卡在 downloading 或 Resolving dependencies
卡在 downloading 多半是直连 packagist.org：DNS 解析慢、TLS 握手超时、单连接限速，每个包都串行等响应。不是你带宽小，是默认链路没优化。
卡在 Resolving dependencies 则和网络无关，常见于：composer.lock 缺失或未提交、minimum-stability 设为 dev、项目中存在已下线的私有仓库（Composer 会逐个超时重试）、或 CLI 模式下 OPcache 被禁用（PHP 会反复编译 Composer 自身代码）。
验证方式：运行 composer config --list --global 和 composer config --list 对比，确认实际生效的 repositories 是哪个；临时绕过所有自定义源试试：composer install --no-plugins --repository=https://packagist.org。
composer config -g prefer-dist true 必须配合镜像才有效
--prefer-dist 告诉 Composer 优先下载预打包的 ZIP/TAR（dist），而不是 clone Git 仓库（source）。但国内镜像源（如阿里云、腾讯云）只缓存 dist 包，几乎不缓存 source —— 如果镜像没切成功，--prefer-dist 就会 fallback 到慢速 source，甚至直接失败。
必须同步执行：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/-
composer clear-cache（旧缓存可能仍指向海外元数据） - 检查是否生效：
composer config -g repo.packagist输出应含"url": "https://mirrors.aliyun.com/composer/"
注意："config": {"prefer-source": true} 在项目 composer.json 中会覆盖全局 prefer-dist，必须手动删掉。
parallel-downloads 参数只对 composer install 有效，且需 Composer 2.2+
parallel-downloads 是 Composer 2.2+ 内置的并发机制，默认值是 3，基本等于没开。设为 10 可让多个 dist 包同时下载，但前提是镜像支持 HTTP/2 多路复用，否则并发请求会被排队堵死。
推荐设置：
- 全局启用：
composer config -g parallel-downloads 10 - CI 脚本中显式带上：
composer install --prefer-dist --no-dev --no-autoloader --no-scripts --no-progress - 如果遇到
file_put_contents(/tmp/): failed to open stream，说明并发过高触发临时文件竞争，降到6或8再试
⚠️ composer update 不受 parallel-downloads 影响，它依赖图计算仍是串行逻辑；日常部署只用 install，update 仅限开发机执行。
CI/CD 环境里最容易被忽略的三个减速点
很多团队开了镜像、加了 --prefer-dist，但 CI 构建仍慢，问题常出在以下三点：
-
--no-autoloader和--no-scripts没加：生成 autoload 文件、执行post-install-cmd（比如npm install或php artisan optimize）会吃掉 30%+ 时间；后续补一次composer dump-autoload --optimize更可控 - 杀毒软件实时扫描
vendor/目录：Windows Defender 或 macOS Gatekeeper 会在每个file_put_contents调用时拦截，解压几百个小文件时 I/O 吞吐可从 120MB/s 掉到 8MB/s；CI 容器中建议关掉实时防护 - 用了已停更的
hirak/prestissimo插件：它在 Composer 2.x 中失效，甚至会静默降级为单线程；请运行composer global remove hirak/prestissimo并确认composer diagnose不再提示该插件
真正快的 CI 构建不是靠“魔法参数”，而是明确知道哪一步可以跳过、哪一步必须补、以及哪些外部因素（DNS、TLS、杀软）正在悄悄拖后腿。
