composer config -g repo.packagist 命令必须同时满足三点才生效：①键名严格为 repo.packagist（非 repos 或 packagist.org）；②type 值必须显式指定为 composer；③URL 必须为 https 开头且末尾带 /。
composer config -g repo.packagist 总不生效？三个硬性条件缺一不可
不是网络慢，是命令写错了，而且错得悄无声息——不报错、不提醒、直接 fallback 到 packagist.org。
必须同时满足以下三点，否则配置无效：
-
repo.packagist（注意是 单数repo，写成repos.packagist或packagist.org都不行） -
composer（这是type值，不是可选参数，也不是注释；漏掉就会走默认源） -
https://mirrors.aliyun.com/composer/（必须用https，且末尾/不能少；少斜杠会拼出/composerpackages.json导致 404）
正确命令示例：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
验证是否写入成功：composer config -g repo.packagist。输出必须是完整 JSON 对象，例如：{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。返回空、null 或报错，说明没生效。
项目级配置为什么比全局更可靠？
全局配置看着省事，但在团队协作和 CI 环境里容易引发行为不一致问题：不同成员本地配的镜像不同，composer.lock 的 hash 就会不一致；CI 流水线若以 www 用户运行，而 -g 配的是 root 或当前登录用户的配置，等于白配。
项目级配置写进 composer.json，所有人拉代码后行为一致。操作很简单：
- 进项目根目录，运行：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（去掉-g） - 该命令会自动在
composer.json顶层repositories字段下追加一条"packagist"记录，key 固定为"packagist"，不会覆盖已有私有源 - 务必手动补上
"packagist.org": false，否则 Composer 仍可能 fallback 到官方源触发超时
提交 composer.json 到 Git，所有协作者和 CI 都能拿到一致行为。
换源后还是卡在 “Loading composer repositories”？缓存和旧文件没清干净
Composer 会优先读取本地缓存和 composer.lock 中记录的元数据地址。哪怕你已经换了源，它也可能还在用旧 URL。
正确操作顺序必须严格按以下三步执行：
- 先运行：
composer clear-cache - 删掉项目下的
vendor/和composer.lock - 再执行：
composer install -vvv（加-vvv才能看到真实请求域名）
日志里出现 mirrors.aliyun.com 或 mirrors.tuna.tsinghua.edu.cn，才表示真正走镜像；如果还看到 packagist.org，说明配置或清理没到位。
composer update 卡在 “Resolving dependencies”？这和镜像源完全无关
镜像只加速下载，不解决依赖解析慢的问题。如果你发现 composer update 卡在 Resolving dependencies 几十秒甚至几分钟，基本可以确定是本地环境或 composer.json 写法导致的。
常见真实诱因包括：
-
"php": "^7.4 || ^8.0"这类宽泛版本约束，让 Composer 在大量 PHP 版本包间反复试探 -
require-dev里塞了太多未锁定版本的工具链，比如"phpunit/phpunit": "^10"+"infection/infection": "dev-main" - 项目用了老旧的
minimum-stability: dev，触发全量元数据拉取
这类问题改镜像源毫无作用，得从 composer.json 的约束粒度和稳定性设置入手。
