最稳的 Composer 镜像设置是执行 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，四要素缺一不可：-g、单数 repo.packagist、type 值 composer、末尾带斜杠的 HTTPS 地址；项目级 repositories 会覆盖全局配置，ECS 用户应改用内网 HTTP 地址。
最稳的 Composer 镜像设置不是堆 URL，而是用一条正确命令配好阿里云 HTTPS 镜像，并关掉干扰项——其他操作多数白忙，还容易引入兼容性问题。
composer config -g repo.packagist 命令必须带全这四个部分
这条命令不是“大概对就行”，漏一个就静默失效：
-
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/—— 四个元素缺一不可：-g（全局）、repo.packagist（单数，不能是repos.packagist）、composer（type 值，不是可选，不是注释）、https://mirrors.aliyun.com/composer/（末尾斜杠/不能少） - 写错
repos.packagist：配置写进无用字段，composer config -g repo.packagist查出来是空，install 还走官方源 - URL 少斜杠（如
https://mirrors.aliyun.com/composer）：请求路径拼成/composerpackages.json，直接 404，不报错但卡住 - Windows 用户改完要重启终端，否则 PHP 进程读不到新环境变量
为什么改了还是走 packagist.org？优先级比你想的高得多
Composer 的源选择是硬规则，不是“谁先配谁生效”：
- 项目根目录下
composer.json里只要出现"repositories"字段（哪怕只有一行空数组），全局镜像立刻失效 - CI/CD 或 Docker 构建时，
sudo composer config -g写进了root用户的~/.composer/config.json，但构建用的是www-data或普通用户，根本读不到 - 验证是否真生效，别信
config -g输出，跑composer diagnose看Repo packagist.org:后面是不是你设的地址；或者加-vvv跑composer update，grepmirrors.aliyun.com
卡在 “Loading composer repositories” 30 秒？不是镜像没配，是超时太短
Composer 默认单源等待 30 秒才切下一个——它不判断连接失败，只等满时间。DNS 慢、TLS 握手卡、IPv6 fallback 都会拖满这 30 秒：
- 临时缓解：加
composer config -g http.timeout 600把超时拉到 10 分钟 - 更治本：设环境变量
COMPOSER_IPV4=1，强制走 IPv4，绕过 IPv6 探测延迟（尤其在某些云主机或校园网） - 别信“多加几个镜像源就能快”，
repositories数组里放多个源，只有前一个返回 404（包确实不存在）才触发下一个；连接超时、502、证书错误都不会 fallback，只会死等
ECS 或内网部署必须用内网地址
阿里云 ECS 用户如果还在用公网 HTTPS 镜像，等于主动给自己加延迟和流量成本：
- 正确内网地址：
http://mirrors.cloud.aliyuncs.com/composer/（注意是http，不是https；无证书校验，VPC 内直连，实测延迟 - 命令：
composer config -g repo.packagist composer http://mirrors.cloud.aliyuncs.com/composer/ - ⚠️ 内网地址仅限阿里云 VPC/经典网络内访问，本地开发机、非阿里云服务器会连不上
- 腾讯云、华为云镜像目前公网稳定性一般，实测偶发 502 或 TLS 握手失败，不建议跨云混用
真正影响稳定性的，从来不是镜像数量，而是你有没有关掉默认源、有没有强制 IPv4、有没有延长超时、有没有确认当前用户上下文——这些细节，比反复执行 config 命令重要十倍。
