旧项目加镜像必须手动编辑composer.json的repositories数组：首项为{"packagist.org": false}，次项为阿里云镜像{"type":"composer","url":"https://mirrors.aliyun.com/composer/"}，并删除vendor与composer.lock后执行composer install。
旧项目加镜像必须改 composer.json 的 repositories 字段
直接在旧项目根目录执行 composer config repo.packagist composer https://mirrors.aliyun.com/composer/ 是错的——它会把整个 repositories 对象替换成单条镜像，清空你原来配的私有源、Git 包或 path 类型仓库。
正确做法是手动编辑 composer.json，确保结构合法且不破坏原有配置：
- 先确认
repositories字段是否存在：不存在就新建；存在就只往数组里追加，别覆盖 - 必须把
{"packagist.org": false}放在repositories数组第一个位置，否则 Composer 仍会 fallback 到官方源 - 阿里云镜像条目要写成：
{"type":"composer","url":"https://mirrors.aliyun.com/composer/"}，url末尾的/不可省略 - 如果项目已用私有 Git 源（如
"my-vcs": {"type": "vcs", "url": "https://git.example.com/pkg"}），把它放在packagist.org禁用项之后、阿里云镜像之前或之后都行，但不能删
composer.lock 和缓存不清理，新镜像等于没配
旧项目大概率已有 composer.lock，里面硬编码了所有包的下载地址和 hash。哪怕镜像配置全对，composer install 仍会按 lock 文件里的原始 URL 去拉包，根本不会走新镜像。
必须做两件事：
- 删掉
vendor/和composer.lock（不要只删 vendor） - 运行
composer clear-cache，否则旧的packages.json元数据还在缓存里，composer update可能仍请求packagist.org
验证是否生效：执行 composer update -vvv，搜日志里的 GET 行，确认域名是 mirrors.aliyun.com 而不是 packagist.org。
项目级镜像优先级高于全局，别被 composer config -g 迷惑
只要 composer.json 里有 repositories 字段，全局配置（~/.composer/config.json 里的 repo.packagist）就完全失效。这是设计行为，不是 bug。
排查时容易踩的坑：
- 执行
composer config -g repo.packagist看到阿里云地址，就以为生效了——其实项目级配置已屏蔽它 - 执行
composer config repo.packagist（无-g）输出为空，误以为没配，其实是字段名不对（应查composer config repositories） - CI 脚本里写了全局换源命令，但项目
composer.json有repositories，结果 CI 还是慢
最稳的做法：旧项目统一走项目级配置，删掉全局镜像干扰，避免权限、用户身份、多环境不一致问题。
Composer 1.x 和 2.x 的 key 名不兼容，老项目要特别注意
如果你维护的是 PHP 5.6 或 Laravel 5.1 之类的老项目，很可能还在用 Composer 1.x。它的镜像 key 是 packagist，不是 repo.packagist。
执行命令时必须区分：
- Composer 2.x：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/ - Composer 1.x：
composer config packagist composer https://mirrors.aliyun.com/composer/（少repo.）
写错 key 名不会报错，而是静默忽略。验证方式只有一个：composer config repositories 输出里有没有你设的 url。没有，就是 key 名错了。
