composer config -g repo.packagist 命令常静默失效，主因是键名错（应为单数repo.packagist）、漏type值composer、url末尾缺/，三者任一出错即回退官方源；项目级repositories字段存在时全局配置被完全屏蔽。
直接执行 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 就能生效，但漏掉任意一个细节（键名、type、末尾斜杠）都会静默失败——install 还是连 packagist.org。
为什么 composer config -g repo.packagist 常常没反应
命令跑完没报错，但 composer install 依然卡在 Loading composer repositories，根本不是网络问题，而是配置压根没被识别：
-
repo.packagist写成repos.packagist（多一个 s）：字段存进无效位置，composer config -g repo.packagist查不到输出 - 漏掉中间的
composer（type 值）：命令变成composer config -g repo.packagist https://...，Composer 2.x 会 fallback 到默认源 - URL 缺末尾
/：比如写成https://mirrors.aliyun.com/composer，实际请求路径变成/composerpackages.json，直接 404 - Windows 下用 Git Bash 时，
COMPOSER_HOME未生效，实际读的是%APPDATA%\Composer\config.json，但你改的是~/.composer/config.json
项目里有 repositories 字段，全局配置就失效
只要项目根目录的 composer.json 里存在 "repositories" 字段（哪怕只是空数组或只写了 {"packagist.org": false}），全局设置就会被完全屏蔽——这是 Composer 的设计逻辑，不是 bug。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 检查方式：
grep -A5 repositories composer.json或打开文件直查看 - 临时绕过：
composer config --unset repositories（不加-g，只删当前项目级配置） - 想保留私有源又加镜像？别手写 JSON，用命令合并：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（无-g） - CI/CD 中若用
sudo composer config -g，写入的是 root 配置，但构建用户可能读不到，应避免 sudo
验证是否真走镜像，别信“命令执行成功”
下载变快 ≠ 走了镜像。Composer 元数据可能从镜像拉，但 zip 包仍从 GitHub 下载（尤其 dist-url 硬编码时）。最可靠验证方式：
- 运行
composer update -vvv | grep "GET "，确认日志中出现的是mirrors.aliyun.com或你配的镜像域名 - 查配置是否写入：
composer config -g repo.packagist.url应输出完整 URL；composer diagnose中 “Repo packagist.org:” 后面的地址也得匹配 - 必须清缓存：
composer clear-cache，否则旧的packages.json元数据还在本地，install 仍连错源 - 如果
composer config -g repo.packagist输出为空，说明配置根本没生效，优先检查键名和路径
最易忽略的一点：Composer ≥2.2 推荐用新键名 repositories.packagist.org，但旧命令不会自动覆盖它。若之前设过，得先 composer config -g --unset repositories.packagist.org 再重设，否则新旧配置共存反而触发警告或 fallback 行为。
