最稳的全局镜像源配置命令是：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，需严格确保键名正确（repo.packagist，非repos）、type值显式写composers、URL末尾带/，否则静默失效。
改镜像源不是换 URL 就完事，repo.packagist 键名写错、漏 composer 类型、URL 缺末尾 /，三者任一出错都会静默失效——命令跑完没报错，composer install 还卡在 Downloading https://packagist.org/packages.json。
怎么用一条命令永久改全局镜像源
最稳方式就是执行：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
这条命令直接写入 ~/.composer/config.json（Windows 是 %APPDATA%\Composer\config.json），所有项目默认生效。注意三点：
-
repo.packagist是固定键名：不能写成repos.packagist（多一个 s）、mirror或repositories，否则 Composer 完全忽略 - 中间的
composer是 type 值：必须显式写出，漏掉会 fallback 到官方源 - URL 必须以
/结尾：写成https://mirrors.aliyun.com/composer会导致拼出/composerpackages.json，404 报错
为什么 composer config -g repo.packagist 输出为空
说明配置根本没被识别，不是命令失败，而是字段存错了位置。常见原因：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 误用了
repos.packagist（复数）：它会被写进无效字段，composer config -g repo.packagist查不到 - 之前用过
composer config -g repos.packagist，得先清理：composer config -g --unset repos.packagist - Composer ≥2.2 推荐用新键名
repositories.packagist.org，但旧命令不会自动覆盖它，得手动--unset再设 - Windows 下 Git Bash 和 CMD/PowerShell 的路径不互通，改完记得重开终端再验证
项目级配置优先级高于全局，怎么避免被覆盖
只要项目根目录有 composer.json 并含 "repositories" 字段，全局设置就自动失效。这不是 bug，是设计行为。应对方法：
- 进项目目录后先运行
composer config repo.packagist，看是否已有输出；有则说明项目自己写了源 - 想保留项目私有源又加镜像？别手写 JSON，用命令安全合并：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（不带-g） - 如果
composer.json里"repositories"是数组（如含私有包），命令会失败，需先手动转成对象："repositories": {} - CI/CD 环境下注意用户身份：用
sudo composer config -g写的是 root 的配置，但构建用的是 runner 用户，得配对应用户的~/
怎么确认镜像真在用，而不是“看起来快了”
下载变快 ≠ 走了镜像，元数据可能走镜像，ZIP 包仍从 GitHub 拉（尤其当 composer.lock 里硬编码了 dist-url）。验证必须看实际请求：
- 先清缓存：
composer clear-cache，否则旧元数据干扰版本匹配 - 删掉
vendor/和composer.lock，再跑composer install -vvv - 搜日志里的
GET行，确认域名是mirrors.aliyun.com或你配的镜像地址 - 或者用
composer diagnose，看输出中Repo packagist.org:后面是不是你设的 URL
复杂点在于：镜像源配置、缓存、lock 文件、项目级覆盖、用户权限这五层，任何一层没对齐，都会让你以为改成功了，其实还在连 packagist.org。
