composer config -g repo.packagist 总不生效是因为三个硬性条件缺一不可：键名必须为单数 repo.packagist、type 值必须显式写 composer、URL 必须 HTTPS 且末尾带 /；任一错误即静默回退官方源，且不报错。
配镜像源不是换地址就行，90% 的失败都卡在 composer config -g repo.packagist 这条命令写错——漏 -g、键名多写一个 s（比如 repos.packagist）、composer 这个 type 值被当成注释省略，或者 URL 少了末尾 /，任一出错就静默 fallback 到 https://packagist.org，连报错都没有。
composer config -g repo.packagist 为什么总不生效
根本原因不是网络卡，而是命令遗漏三个硬性条件：
-
repo.packagist必须是单数形式，写成repos.packagist或packagist.org都无效 - 中间的
composer是必需的type值，不能省略，也不能替换成其他字符串 - URL 必须是 HTTPS 且末尾带
/，例如https://mirrors.aliyun.com/composer/✅；少斜杠会拼出/composerpackages.json导致 404 ❌
验证是否真写入：运行 composer config -g repo.packagist，输出必须是完整 JSON 对象，形如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。空、null、报 Key not found，或只返回字符串（如 "https://packagist.org"），都说明没配成功。
项目级配置比全局更可靠
全局配置写在 ~/.composer/config.json，但 CI 流水线用 runner 用户、宝塔用 www 用户、Docker 容器可能以非登录用户运行——它们根本读不到你的全局配置。
- 进项目根目录（含
composer.json），执行：composer config repo.packagist composer https://mirrors.aliyun.com/composer/（注意不带-g） - 该命令会自动识别
composer.json中已有的repositories结构：如果是对象，就写入"packagist"键；如果是数组，就追加新项，不破坏私有源 - 如果
composer.json原本是"repositories": []（数组），命令会失败；需先手动改成"repositories": {}再重试 - 千万别手动写
"packagist.org": false——这会导致php、ext-json等基础约束校验失败
换源后仍卡在 “Loading composer repositories”
这不是镜像没生效，而是 Composer 还在读旧缓存和旧 composer.lock。
- 先清缓存：
composer clear-cache - 删掉项目下的
vendor/和composer.lock - 再跑
composer install -vvv，观察日志里是否出现mirrors.aliyun.com或mirrors.cloud.tencent.com - 如果日志里还是
packagist.org，说明镜像根本没走通，回头检查上面两个副标题里的硬性条件
哪些镜像地址现在还能用（2026 年 8 月实测）
截至今天，只有这三个镜像全量同步、HTTPS 强制、延迟稳定（5 分钟内），其余旧地址基本不可靠：
- 阿里云：
https://mirrors.aliyun.com/composer/ - 腾讯云：
https://mirrors.cloud.tencent.com/composer/ - 华为云：
https://mirrors.huaweicloud.com/repository/php/
清华源偶尔 DNS 解析慢，SJTUG 源对出口 IP 有白名单限制，php.cnpkg.org 文档弱、出问题只能靠社区反馈——这些都不是不能用，而是需要额外判断是否适配你当前环境的真实出口链路。
