唯一可靠方式是执行 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，必须满足三点：键名准确、含 composer 类型声明、url 末尾带斜杠；否则静默失效。
执行 composer config -g repo.packagist 是唯一可靠方式
改镜像不是换 URL 就完事，漏掉任意一个关键要素都会静默失效——命令不报错，但 composer install 依然连 packagist.org。必须严格满足三点：repo.packagist（不能拼成 repos.packagist 或 mirror）、中间的 composer 类型声明、URL 末尾带 /。
正确命令是：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
常见错误包括：
- 写成
https://mirrors.aliyun.com/composer（缺末尾斜杠），导致请求路径变成/composerpackages.json，404 - 漏掉中间的
composer，2.x 版本会 fallback 到默认源，不提示 - Windows 用户改完没重开终端，
env缓存未刷新，composer config -g repo.packagist查不到新值
验证是否真走镜像，别信“命令跑完了”
下载变快 ≠ 走了镜像。Composer 元数据（如 packages.json）可能走了镜像，但 zip 包仍从 GitHub 直下（尤其项目里硬写了 dist-url）。最可靠验证法是开调试日志：
composer update -vvv | grep "GET "
确认输出中出现的是 mirrors.aliyun.com 或你配的镜像域名。同时检查两处配置状态：
-
composer config -g repo.packagist—— 看全局有没有输出 -
composer config repo.packagist（无-g）—— 看当前项目是否覆盖了全局 -
composer diagnose输出中找Repo packagist.org:后面的地址，不是你设的镜像就说明没生效
为什么不能只改 composer.json 里的 repositories
项目级 repositories 字段优先级高于全局，一旦存在，repo.packagist 配置直接被忽略。这不是 bug，是 Composer 的设计逻辑。更麻烦的是，它不覆盖，而是合并——若依赖包自身也声明了 repositories（比如私有 SDK），就会触发多源并发请求，反而拖慢甚至冲突。
若真需项目级控制，必须显式禁用默认源：
{"repositories": [{"packagist.org": false}, {"type":"composer","url":"https://mirrors.aliyun.com/composer/"}]}
且执行后务必运行 composer clear-cache，否则旧缓存的元数据仍参与版本解析。
换镜像后仍卡在 loading package information？先查环境干扰
镜像只是加速手段，真正卡住常和网络环境或本地配置有关：
- 代理残留：
env | grep -i proxy检查是否设置了HTTP_PROXY或HTTPS_PROXY；Composer 不自动绕过代理，即使镜像在国内也会被转发出去 - DNS 污染：运行
ping mirrors.aliyun.com，若解析到异常 IP，临时换 DNS（如114.114.114.114）并清本地缓存 - SSL 校验失败：某些企业网络拦截 HTTPS，可临时禁用（仅调试）：
composer config -g secure-http false，完事后务必恢复 - 锁文件陈旧、PHP 扩展缺失（
openssl、zip）、vendor权限混乱，都比镜像本身更容易导致失败
别只盯着源地址，先跑通 composer diagnose —— 它能暴露 80% 的真实瓶颈。
