答案是因三个硬性条件未同时满足：必须带-g、键名严格为repo.packagist（非repos）、第二参数必填composer类型值，且URL须以/结尾；任一缺失即静默回退至packagist.org。
composer config -g repo.packagist 命令为什么总不生效
执行 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 后仍走 packagist.org，90% 是因为三个硬性条件没同时满足：
– 必须带 -g，否则只改当前项目；
– 键名必须是 repo.packagist（不是 repos.packagist，多一个 s 就静默失败）；
– composer 是 type 值，不是注释，不能省略；
– URL 必须 HTTPS 且末尾带斜杠，https://mirrors.aliyun.com/composer/ ✅，https://mirrors.aliyun.com/composer ❌（拼成 /composerpackages.json 导致 404）。
验证镜像是否真在用，别只看命令有没有报错
运行 composer config -g repo.packagist，输出必须是完整 JSON 或纯 URL 字符串：
– 正确示例：{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} 或 https://mirrors.aliyun.com/composer/；
– 空、null、https://packagist.org 或报错，说明配置根本没写进去；
– 更直接的验证：删掉 vendor/ 和 composer.lock，执行 composer install -vvv，日志里出现 mirrors.aliyun.com 才算真正生效；
– 如果 CI 或 Docker 容器里跑不生效，大概率是用户权限不一致——你在宿主机 root 下配的，但容器里以 www 或 runner 用户运行，读的是它自己的 ~/.composer/config.json。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
项目级配置比全局更可靠，尤其适合团队和 CI
进项目根目录，运行：
– composer config repo.packagist composer https://mirrors.aliyun.com/composer/（去掉 -g）；
– 它会自动往 composer.json 的 repositories 字段安全追加，不覆盖已有私有源；
– 如果 composer.json 里 "repositories" 是数组（[]），命令会失败，需先手动改成对象（{}）；
– 改完必须删掉 vendor/ 和 composer.lock，再跑 composer install，否则旧 lock 文件里的哈希和镜像元数据不匹配，会报 hash does not match。
换源后还卡在 Resolving dependencies？那和镜像无关
Resolving dependencies 卡住几十秒，不是镜像问题，而是本地解析逻辑拖慢：
– PHP 版本约束太宽，比如 "php": "^7.4 || ^8.0 || ^8.1"，会让 Composer 尝试大量组合；
– require-dev 里塞了太多未锁定版本的工具包（如 "phpunit/phpunit": "dev-main"）；
– 用了已废弃的 fxp/composer-asset-plugin（常见于老版 Yii2），它不走 Composer 镜像，额外请求 Bower/NPM 源；
– 解决办法：收紧 config.platform.php，删掉不必要的 dev 包，或升级到 yiisoft/yii2 2.0.14+ 改用 npm-asset-packagist。
