答案：改镜像后仍卡在“loading composer repositories”主因是本地缓存未清、composer.lock残留旧url或项目级repositories覆盖全局配置；须执行composer clear-cache、删vendor/和composer.lock、再运行composer install -vvv验证日志是否请求镜像域名。
为什么改镜像后还是卡在 “Loading composer repositories”
不是镜像地址错了，而是 Composer 仍在读旧缓存或旧 lock 文件。它不会因为配置更新就自动刷新元数据请求路径。
- 必须先运行
composer clear-cache清掉本地缓存 - 删掉项目下的
vendor/和composer.lock（否则composer install仍按 lock 里记录的原始 URL 回源） - 执行
composer install -vvv，观察日志中是否出现你配置的镜像域名（如mirrors.aliyun.com），而非repo.packagist.org - 若仍走官方源，检查是否被项目级
repositories覆盖——项目配置优先级高于全局，且不报错
composer config -g repo.packagist 命令为何静默失效
这条命令对字段名、type 值、URL 格式有硬性要求，缺一即无效，且不提示错误。
- 键名必须是
repo.packagist（不是repos.packagist、mirror或其他变体） - 中间的
composer是type值，不是域名，也不能省略或写成composer.org - URL 必须以
https://开头，且末尾带/（例如https://mirrors.tencent.com/composer/✅，少斜杠会拼出/composerpackages.json导致 404） - 验证是否生效：运行
composer config -g repo.packagist，输出必须是完整 JSON 对象，形如{"type": "composer", "url": "https://mirrors.huaweicloud.com/repository/php/"}
阿里云、腾讯云、华为云镜像的实际差异在哪
三家都同步 packagist.org，但策略不同，直接影响 composer update 的成功率和响应速度。
- 阿里云（
https://mirrors.aliyun.com/composer/）：同步延迟约 5–10 分钟；华北节点快，华东偶发 502；适合日常开发，CI 场景慎用 - 腾讯云（
https://mirrors.cloud.tencent.com/composer/）：CDN 覆盖广，南方用户稳定；不保留已删包，遇到Package not found可能是原包下架，非镜像问题 - 华为云（
https://mirrors.huaweicloud.com/repository/php/）：全量镜像，含历史版本；metadata 请求略慢（因分片存储），但同步延迟最低 - 测试建议：清缓存后跑
time composer update --dry-run，重点看是否出现Connection refused或SSL certificate problem——后者多因镜像用了过期中间证书
私有包找不到，是不是镜像没配好
不是。镜像只加速公共包（packagist.org 上注册的包），私有包完全不受影响。报 Could not find package acme/utils，说明 Composer 根本不知道去哪里找。
- 必须在项目
composer.json的repositories字段中显式声明私有源，类型为composer，URL 指向可访问的packages.json（如 Satis 或 Artifactory 提供的地址） - 私有源和公共镜像不能混在一个
url下，必须分开写两条{"type": "composer", "url": "..."}对象 - 顺序决定匹配优先级：建议把私有源放在
repositories数组靠后位置，避免意外覆盖开源包 -
composer outdated --all对私有包无效——它只查packagist.org元数据，不会主动轮询你的内网源
provider-*.json 文件缺失导致 fallback 到全量 packages.json，才是卡住的真正原因。
