结论：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 命令有效，但需满足三个硬性条件：必须加 -g、键名严格为 repo.packagist（非 repos 或 packagist.org）、url 末尾必须带斜杠 /。
直接说结论：现在配 Composer 国内镜像，composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 这条命令能用，但 90% 失败不是因为网络，而是写错了三个硬性条件——漏 -g、键名写成 repos.packagist 或 packagist.org、URL 少了末尾斜杠 /。
为什么 composer config -g 总是静默失败？
这条命令不报错也不提示，但实际没生效，常见原因就三个：
-
-g缺失 → 只改当前项目composer.json，换目录就失效 - 键名写错 → 必须是
repo.packagist（单数repo，不是repos；不能是packagist.org） - URL 少斜杠 →
https://mirrors.aliyun.com/composer（没/）会拼出/composerpackages.json，404
验证是否真生效，别只看命令有没有报错，运行：composer config -g repo.packagist
输出必须是类似：{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}
哪些镜像地址现在还能用（2026 年实测）？
截至 2026 年 7 月，以下三个 HTTPS 镜像全量同步、稳定可用：
- 阿里云：
https://mirrors.aliyun.com/composer/ - 腾讯云：
https://mirrors.cloud.tencent.com/composer/ - 华为云：
https://mirrors.huaweicloud.com/repository/php/
别再用 packagist.phpcomposer.com 或 packagist.laravel-china.org —— 已跳转失效或响应极慢。执行命令时，URL 必须带 https:// 和结尾 /，否则部分 Composer 版本（尤其是 2.9+）会路径拼接错误。
全局配置 vs 项目级配置，到底该选哪个？
全局看着省事，但实际容易在 CI/CD 或团队协作中翻车：
- CI 环境（如 GitHub Actions）默认不读
~/.composer/config.json，得显式设COMPOSER_HOME - 项目里若已有
"packagist.org": false，全局镜像会被直接屏蔽 - 新人 clone 项目后行为不一致，因为全局配置无法被 Git 跟踪
推荐做法：进项目根目录，运行composer config repo.packagist composer https://mirrors.aliyun.com/composer/
（去掉 -g）——它会自动往 composer.json 里加 "repositories" 字段，且不会覆盖已有的私有源。
配完还是卡在 “Loading composer repositories” 怎么办？
这不是镜像没生效，而是你没清缓存或 PHP 环境有问题：
- 先清 Composer 缓存：
composer clear-cache - 检查
php.ini是否禁用了proc_open或putenv（常见于 PHPStudy 或宝塔），禁用会导致config -g命令根本跑不动 - 验证 PHP 函数是否可用：
php -r "echo proc_open('echo 1', [], $p) ? 'ok' : 'fail';"，输出ok才算过关 - 最后用
composer show -v | head -n 5看真实请求地址，确认日志里出现的是aliyun.com而不是packagist.org
真正容易被忽略的点是：镜像只加速元数据拉取和 ZIP 下载，不解决 Resolving dependencies 卡顿——那通常是 composer.json 里版本约束太宽或 dev 分支太多导致的。
