必须加-g参数，否则修改的是当前项目composer.json而非全局配置；键名必须为repo.packagist（单数）、type必须显式写composer、url须用https且末尾不带/，三者缺一不可，否则静默失效。
直接用 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 就行，其他方式要么不生效、要么埋雷。
为什么必须加 -g（或 --global）
不加 -g 就是改当前项目的 composer.json 里的 repositories 字段，只影响这一个目录。全局镜像要作用于所有项目（包括 create-project、global require），就必须让 Composer 写进用户级配置文件——而这个动作只能靠 -g 触发。
-
composer config repo.packagist ...→ 改当前项目根目录下的composer.json -
composer config -g repo.packagist ...→ 改~/.composer/config.json（Linux/macOS）或%APPDATA%\Composer\config.json（Windows） - 执行后立刻生效，不用重启终端、不用清缓存、也不需要
source任何文件
镜像地址写法必须严格匹配
键名、协议、路径都不能错，否则会静默失败或报错。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 键名固定为
repo.packagist，不是repos.packagist，也不是repository - 必须用
https://，http://在 Composer 2.2+ 默认被拒绝 - URL 末尾不能带
/：✅https://mirrors.aliyun.com/composer，❌https://mirrors.aliyun.com/composer/（部分版本会报Invalid repository type） - 华为云路径特殊：
https://repo.huaweicloud.com/repository/php，不是/composer
验证是否真生效的两个命令
别猜，直接问 Composer 自己读的是哪个源。
- 查全局设置：
composer config -g repo.packagist，输出应为完整 JSON 对象，比如{"type": "composer", "url": "https://mirrors.aliyun.com/composer"} - 查当前上下文实际生效源：
composer config repo.packagist（不加-g），如果在项目目录下运行，它优先返回项目composer.json里定义的源；如果提示Key "repo.packagist" does not exist，才说明真正落到全局配置上 - 再跑一次
composer show packagist/support，看请求 URL 是不是走你设的镜像域名（比如mirrors.aliyun.com）
常见失效原因和对应解法
配置写了但还是慢、卡住、或者继续走官方源，大概率不是命令错了，而是环境干扰。
- 项目级
composer.json里写了repositories→ 全局设置被完全覆盖，删掉或注释掉该项目的repositories字段 - Docker/CI 环境没持久化全局配置 → 构建阶段显式执行
RUN composer config -g repo.packagist composer https://mirrors.aliyun.com/composer - 用了
sudo composer→ 配置写进了 root 用户的~/.composer/，普通用户执行时读不到，去掉sudo - 多个 Composer 版本共存（brew + snap + 手动安装）→ 检查
which composer和composer --version路径是否一致
最易忽略的一点：全局镜像只对 Packagist 类型仓库生效，GitLab 私库、GitHub 私包、VCS 类型源不受影响——它们走自己定义的 type: vcs 或 type: package，该配认证还得配认证。
