最靠谱的镜像配置是写入composer.json的repositories数组首项禁用官方源并指定镜像url，因全局配置易被覆盖、ci失效且难统一管理；必须用数组格式、首项{"packagist.org": false}、镜像url末尾带/，且需删除vendor和composer.lock后执行composer install。
composer.json 里写死镜像，比发配置文件靠谱得多——发文件根本管不住人，也进不了 Git，更不会被 CI 读到。
为什么分发 ~/.composer/config.json 是无效操作
团队发一个全局配置文件让所有人覆盖 ~/.composer/config.json，看似统一，实则埋雷：
• 新成员漏执行、执行权限不对（比如用 root 写了，但 PHP 进程以 www-data 跑）、或 IDE 自带 Composer 指向另一个用户目录
• CI/CD 容器没家目录，~/.composer 根本不存在，配置直接失效
• 多个项目共用同一全局配置，A 项目要用私有源 + 阿里云镜像，B 项目要禁用 packagist.org，全局配置无法差异化
• composer config --global 写入的字段可能格式错误（比如少逗号、引号不闭合），导致后续所有命令报 JSON 解析失败
composer.json 的 repositories 必须是数组且首项禁用官方源
只往 composer.json 里加一条 "repositories": {"packagist.org": {"type":"composer", "url":"https://mirrors.aliyun.com/composer/"}} 不够，Composer 2.2+ 会忽略它——元数据请求仍走硬编码的 packagist.org。
必须用数组形式，并确保第一项是显式禁用：
"repositories": [
{"packagist.org": false},
{
"type": "composer",
"url": "https://mirrors.aliyun.com/composer/"
}
]
• {"packagist.org": false} 必须是独立对象，不能合并进下一项
• url 末尾必须带 /，否则请求变成 https://mirrors.aliyun.com/composer/packages.json（404）
• 如果项目已有私有仓库，把它插在第二项之后，别删掉第一项
改完 composer.json 后，vendor 和 composer.lock 必须全删
常见错误：改完 repositories 就跑 composer update，结果包还是从 packagist.org 下——因为 composer.lock 里存的是旧 dist URL，Composer 完全不查新配置。
必须手动清理：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
rm -rf vendor composer.lock-
composer install（不是update）
• composer install 才会重新解析 composer.json 并生成新 lock 文件
• CI 脚本里要加 rm -f composer.lock && rm -rf vendor，否则缓存会复用旧 lock
• 别信 composer update --dry-run 的输出，它不验证元数据源是否生效
CI 和本地都要防全局配置污染
哪怕项目级配置写对了，只要某台机器上还留着 composer config --global repo.packagist，就可能干扰行为——尤其当 composer.json 里 repositories 是空对象或未声明 packagist.org 时。
统一清理动作：
- 所有人运行：
composer config --global --unset repo.packagist - CI 脚本开头加：
composer config --global --unset repo.packagist - 验证是否清干净：
composer config --global repo.packagist应输出Could not find configuration或空行
真正麻烦的不是配不配镜像，而是有人配了又忘了删，或者配错键名（比如写成 repos.packagist），这种错误不报错、不提示，只在某次 composer install 卡住时才暴露。
