Composer安装慢90%非网络问题，而是镜像未生效、parallel-downloads未正确启用、--prefer-dist被项目配置覆盖或缓存未清除；需验证config输出为完整JSON、设parallel-downloads=10~15、删composer.json中prefer-source、清缓存并确认下载域名。
Composer 安装慢，90% 不是网络差，而是镜像没切对、parallel-downloads 没生效、--prefer-dist 被覆盖或缓存没清——这四点错一个，提速就打折扣。
怎么确认镜像源已真正生效
很多人执行了 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 就以为完事了，但实际可能静默失败。关键看输出是否为完整 JSON：
- 运行
composer config -g repo.packagist，正确输出应类似{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}—— 缺少type、URL 少末尾斜杠、或多写了个s（如repos.packagist），都会 fallback 到 packagist.org - 如果输出为空、
null或报错，说明配置根本没写进去；临时验证可加--repository=https://packagist.org强制走官方源，对比速度差异 - 国内镜像只缓存
dist包，不缓存source；若镜像未生效，--prefer-dist会自动降级为 Git clone，反而更慢
为什么 parallel-downloads 设了还是串行下载
parallel-downloads 是 Composer 2.2+ 的内置并发机制，但默认值是 3，等于没开。它只对 composer install 生效，且严重依赖镜像源支持 HTTP/2 多路复用：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 查当前值：
composer config -g parallel-downloads，输出应为10或15（别超20） - 设全局并发：
composer config -g parallel-downloads 10；注意不是--concurrency，那是旧版或插件参数 - 如果卡在
Downloading xxx且无并发迹象，大概率是镜像未生效或 DNS 缓存未刷新；必须同步执行composer clear-cache - 并发过高会触发临时文件竞争，报
file_put_contents(/tmp/): failed to open stream—— 此时立刻降到6或8
--prefer-dist 和 prefer-source 冲突怎么办
--prefer-dist 告诉 Composer 优先下载 ZIP/TAR 包，但它会被项目级配置强行覆盖。常见于团队协作中误提交的 "prefer-source": true：
- 检查项目根目录
composer.json，搜索prefer-source；只要存在，全局prefer-dist就失效 - 手动删掉该字段，或改用命令移除：
composer config --unset prefer-source - 私有包若只提供
source地址（如 Git URL），--prefer-dist会直接报Could not find a matching version of package xxx，此时只能关掉该参数或补全 dist 发布流程 - 开发机慎用
composer config -g prefer-dist true，否则你改vendor/里的代码会被下次install覆盖
CI/CD 中哪些参数组合能省掉 30%+ 时间
开发机要 autoload 和脚本，但 CI 构建里它们全是冗余。不关掉，vendor 装完也跑不起来——因为 autoload.php 没生成、钩子还可能意外触发 npm install：
- 必加：
--no-autoloader --no-scripts --no-dev --prefer-dist -
--no-autoloader跳过生成vendor/autoload.php，后续用composer dump-autoload --optimize单独补 -
--no-scripts阻止执行post-install-cmd等钩子，避免 Redis 清空、前端构建等重型操作 - 注意：
--classmap-authoritative只应在 CI 中启用；开发时开了会导致新增类不被识别，且无法 fallback 检查文件是否存在
最易被忽略的是缓存键和 .composer/cache/ 的协同：CI 中只缓存 vendor/ 而不缓存 .composer/cache/files/，下次 install 仍要重下所有 ZIP 包；而缓存键若用错变量（比如 ${CI_COMMIT_TAG} 在非 tag 流水线里 fallback 到默认键），缓存就永远不命中。
