直接执行composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/可解决90%卡顿，但漏-g、键名错为repos.packagist、url末尾缺/任一错误均静默失效；验证必须用-vvv日志确认真实请求域名。
直接执行 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 就能解决 90% 的卡顿问题，但漏 -g、键名写成 repos.packagist、URL 少末尾 /，三者任一出错都会静默失效——命令没报错，composer install 还在连 packagist.org。
全局镜像配置必须写对这三要素
Composer 2.0+（当前主流版本）只认 repo.packagist 这个键名，且必须配合 composer 类型值和完整 URL：
-
-g不能省：缺了就只改当前项目composer.json，换目录即失效 - 键名必须是
repo.packagist（单数，不是repos.packagist或repository.packagist） - 中间的
composer是 type 值，不是可选参数，漏掉会 fallback 到官方源 -
https://mirrors.aliyun.com/composer/必须带末尾/，否则请求路径拼成/composerpackages.json导致 404
验证是否真走镜像，只看 -vvv 日志
不加 -vvv，日志只会显示 “Downloading xxx”，看不出实际域名。只有加了才能确认真实请求地址：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 运行
composer install -vvv 2>&1 | grep "Downloading"，输出里必须出现mirrors.aliyun.com或mirrors.tuna.tsinghua.edu.cn - 如果看到
packagist.org或github.com，说明镜像没生效，或被项目级repositories覆盖 - 临时绕过所有配置验证：用
composer install --no-plugins --repository=https://packagist.org -vvv，如果这时快了，就是本地配置冲突
项目级配置优先级更高，适合团队协作
全局配置在 CI/CD、宝塔后台、同事电脑上都不一定生效，因为它们读的是各自用户的 ~/.composer/config.json。项目级配置写进 composer.json 才真正可靠：
- 进项目根目录后执行：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（不带-g） - 它会自动在
composer.json顶层添加或合并"repositories"字段，key 固定为"packagist" - 如果
composer.json里"repositories"是数组（如含私有包），命令会失败；需先手动改成对象："repositories": {} - 提交
composer.json后，其他成员拉取即生效，无需各自配置
换源后仍卡住？先清缓存再查依赖解析
镜像只加速下载环节，不解决依赖分析慢的问题。如果卡在 Resolving dependencies 或 Loading composer repositories，和镜像无关：
- 必须执行：
composer clear-cache——旧缓存里存着官方源的元数据，不清掉，Composer 仍会尝试校验旧 hash - 删掉
vendor/和composer.lock再重装：lock 文件里的 URL 和 hash 来自旧源，与镜像元数据不匹配会导致中断 - 若卡在
Resolving dependencies，检查composer.json中require版本约束是否太宽（如"^2.0"），或启用了"minimum-stability": "dev" - 某些插件（如已废弃的
hirak/prestissimo）会与新版 Composer 冲突，临时禁用：composer install --no-plugins
最常被忽略的是：镜像只管下载，不管解析；而卡点往往在解析阶段。不看 -vvv 日志，光换源根本找不到真问题。
