正确命令是composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，必须严格满足：-g不可省略、键名repo.packagist为单数、中间参数composer为必需type值、url以https://开头且末尾带斜杠/；否则静默回退官方源。
改了镜像还是慢，90% 的情况不是镜像不行，而是配置根本没生效、缓存没清、或者压根没走新地址——Composer 不报错，但会静默 fallback 到 packagist.org。
composer config -g repo.packagist 命令写对了吗
这条命令必须同时满足三个硬条件，缺一就失效：
-
repo.packagist是唯一合法键名（注意是 单数，repos.packagist多一个 s 就被完全忽略） - 中间必须显式传入
composer作为 type 值：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/✅；漏掉composer就 fallback ❌ - URL 必须是 HTTPS + 末尾带斜杠：
https://mirrors.aliyun.com/composer/✅；https://mirrors.aliyun.com/composer❌（少斜杠会导致请求路径拼成/composerpackages.json，直接 404）
验证是否成功：运行 composer config -g repo.packagist，输出必须是完整 JSON 对象，例如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}；空、null、或仍是 https://packagist.org 都说明没写进去。
缓存没清，镜像再快也白搭
Composer 优先读本地缓存里的元数据（比如 packages.json），哪怕你刚改了镜像，只要缓存里还存着从 packagist.org 拉下来的数据，它就会继续往那儿发请求——直到超时才 fallback，这个过程非常耗时。
- 必须执行
composer clear-cache（不是cache-clear，后者已废弃） - 手动删掉旧缓存目录更彻底：
rm -rf ~/.composer/cache/repo/https---packagist.org/（Linux/macOS） - 临时验证是否真走新源：加
--no-cache再跑一次composer install -vvv，如果变快，就坐实是缓存问题
项目级 repositories 覆盖了全局配置
如果你的项目 composer.json 里已有 "repositories" 字段，它会直接覆盖全局 repo.packagist 设置，哪怕你配了阿里云镜像也没用。
- 检查当前生效的是哪一层：
composer config --list | grep repositories - 确认项目级配置是否含
"packagist.org": false，否则默认仍会回退到官方源 - 更稳妥的做法是进项目根目录，运行
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（不加-g），它会自动向composer.json的repositories字段追加条目
卡在 Resolving dependencies 不是网络问题
这个阶段根本不走网络，是 Composer 在本地穷举满足所有约束的版本组合。镜像再快也救不了它。
- 写了
"*"、"^1.0 || ^2.0"或"minimum-stability": "dev"，求解器会指数级爆炸 -
"php": ">=7.4"比"php": "^8.1"多查几百个包的兼容性元数据 - Xdebug 启用中会让求解器慢 5–10 倍；临时禁用：
php -d xdebug.mode=off $(which composer) install - 确保
composer.lock存在且已提交到 Git，否则每次install都强制重算整个依赖图
真正容易被忽略的是：缓存目录如果落在机械盘、WSL2 挂载的 Windows 目录、加密卷或 NFS 上，解压 ZIP 包时 I/O 就成瓶颈——这比网络慢更隐蔽，也更难排查。
