全局 config -g 在跨国团队基本失效，因其依赖本地用户目录配置，而成员系统环境、ci/cd干净镜像及项目级 repositories 优先级更高，且需显式禁用 packagist.org 并清理缓存、lock 文件与 vendor 才能确保镜像生效。
为什么全局 config -g 在跨国团队里基本失效
因为 composer config -g 写的是当前用户家目录下的 ~/.composer/config.json，而跨国团队成员的系统用户、网络代理、PHP 版本、甚至 shell 初始化方式都不同；CI/CD 环境（比如 GitHub Actions 的 Ubuntu runner 或 GitLab 的 Docker 容器）每次都是干净镜像，根本不会继承你的本地配置。更关键的是：只要项目根目录有 composer.json 且含 repositories 字段，全局配置就完全被跳过——不是优先级低，是压根不读。
项目级配置必须显式禁用 packagist.org 才生效
只运行 composer config repo.packagist composer https://mirrors.aliyun.com/composer/ 不够。Composer 默认仍会 fallback 到官方源，除非你在 composer.json 顶层加这一行："packagist.org": false。它必须和 repositories 同级，不能塞进 repositories 里面。否则 composer install 还是可能绕过镜像直连 packagist.org 或 api.github.com。
常见错误：
- 误把
"packagist.org": false放在repositories对象内部 - 项目已有空
"repositories": []数组，导致composer config命令失败（需先手动改成对象"repositories": {}） - 没删
composer.lock，里面存的仍是旧 dist URL，安装时仍走国外地址
换镜像后必须清缓存 + 删 lock + 重装
镜像只改元数据（packages.json）的请求路径，不改已缓存的 ZIP 包或 lock 文件里的哈希与 URL。所以切换镜像后：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 必须执行
composer clear-cache，否则旧缓存里存的是https://packagist.org的 hash 和路径 - 必须删除
vendor/和composer.lock - 再跑
composer install，让 Composer 重新拉取镜像站的元数据，并生成带mirrors.aliyun.com的 dist URL
这点在跨国团队中尤其致命：A 团队成员在新加坡机器上生成的 lock 文件，B 成员在北京拉下来，如果没重装，dist URL 仍是 api.github.com，直接卡死或 404。
CI 流水线里别信“配置一次就完事”
GitHub Actions、GitLab CI、Jenkins 都不认你本地的 ~/.composer。每轮构建都要确保镜像配置写入项目本身，且验证生效：
- 用
curl -I -s -o /dev/null -w "%{http_code}" https://mirrors.aliyun.com/composer/packages.json探活镜像 - 失败则 fallback 到官方源，并确保
"packagist.org": true或删掉该字段 - 执行
composer config repo.packagist composer $MIRROR_URL/（注意结尾/） - 再补一句
composer config --unset packagist.org或手动写入"packagist.org": false到composer.json
最容易被忽略的细节：所有 CI 脚本里 composer 命令必须以普通用户身份运行，绝不能加 sudo；否则配置写进 root 的 ~/.composer，后续步骤读不到。
