90%的“卡在downloading”是镜像未生效导致元数据请求失败：键名写错（如repos.packagist）、缺type参数、URL少末尾/、未清缓存或被项目级配置覆盖，必须用composer config -g repo.packagist验证输出为完整JSON且日志显示镜像域名。
composer install 卡在 downloading 不是框架大，是镜像根本没生效
国内直连 packagist.org 时，TLS 握手、DNS 解析、首字节延迟全拉垮——你看到的“卡住”，90% 是卡在拉 packages.json 元数据这一步，不是后面下 ZIP 包慢。换镜像不是“提速技巧”，而是让命令能跑起来的前提。
为什么 composer config -g repo.packagist 总是不生效？
这条命令静默失败率极高，但不报错，导致你以为配好了，其实还在走海外源。
-
repo.packagist写成repos.packagist（多一个 s）→ 完全无效 - 漏掉中间的
composer类型参数 → Composer 2.0+ 自动 fallback 到官方源 -
https://mirrors.aliyun.com/composer少了末尾/→ 拼出/composerpackages.json404 - 用普通用户执行，但 CI 或宝塔以
www用户运行 → 读不到你的全局配置
验证唯一方式：composer config -g repo.packagist 输出必须是完整 JSON：{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。空、null、或还是 https://packagist.org，就说明没写进去。
composer install -vvv 日志里还出现 packagist.org？立刻清缓存
缓存比配置更顽固。就算镜像已配对，Composer 仍会优先读本地缓存的旧元数据，根本不发新请求。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 必须执行：
composer clear-cache - 如果项目已有
vendor/和composer.lock，删掉再重装：rm -rf vendor composer.lock && composer install - 某些包硬编码 GitHub URL（比如
"dist": {"url": "https://github.com/xxx/yyy/archive/"}），这类不会走镜像，会撞GithubRateLimit错误
项目级配置比全局更稳，尤其团队和 CI 场景
全局配置无法提交到 Git，CI 流水线也常因用户权限读不到。项目级写入 composer.json 才真正可靠。
- 进项目根目录，运行：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（去掉-g） - 它会自动往
composer.json的repositories字段追加，key 固定为"packagist"，不覆盖私有源 - 如果
repositories原来是数组（[]），命令会失败；需先手动改成对象（{}）再运行 - 别写
"packagist.org": false—— 这会关掉基础包源，镜像一挂，composer install直接失败
parallel-downloads 设太高反而出错
这个参数只对 composer install 有效，composer update 仍串行算依赖图。默认值 3 基本等于没开。
- 推荐设为
10：composer config -g parallel-downloads 10 - 别冲到
20：低配 CI 或企业网络容易触发file_put_contents(): failed to open stream（临时文件竞争） - 该机制依赖镜像支持 HTTP/2 多路复用；阿里云、清华、腾讯都支持，但私有源若不支持，设高了也白搭
最后注意：Resolving dependencies 卡住和镜像完全无关——那是 PHP 版本约束太宽、require-dev 包太多、或用了 "*" 这类模糊版本号导致的求解器爆炸。换源解决不了这个问题。
