Composer镜像配置静默失效主因是repo.packagist键名错误、缺-g参数、漏composer类型值或URL末尾无/，任一缺失即回退官方源；项目级repositories字段会无条件覆盖全局配置。
必须全局配置阿里云或腾讯云镜像源，并执行 composer clear-cache，否则 90% 的超时问题不会解决——不是网络差，是默认走 packagist.org 导致 DNS 解析慢、TLS 握手卡、首字节延迟高。
为什么 composer config -g repo.packagist 总是静默失效
这条命令不报错，但写错任意一个字符就等于没配。三个硬性条件缺一不可：
-
repo.packagist是唯一合法键名，写成repos.packagist、repository.packagist或mirror全部无效 - 中间的
composer是type值，必须显式写出，漏掉它会 fallback 到官方源 - URL 必须以
https://开头且末尾带/：https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌（少斜杠会导致路径拼接错误，返回 404）
验证是否真生效：运行 composer config -g repo.packagist，输出必须是完整 JSON 或至少是镜像 URL 字符串；空、null 或仍显示 https://packagist.org，说明根本没写进去。
项目级配置会完全覆盖全局镜像
只要 composer.json 里有 "repositories" 字段（哪怕只写了 []），全局配置就失效。这是最常被忽略的失效原因。
- 检查是否被覆盖：运行
composer config -l | grep repositories，如果输出带项目路径，说明composer.json已定义源 - 临时绕过验证：加
--repository-url参数强制走镜像，例如composer install --repository-url=https://mirrors.aliyun.com/composer/ - CI/CD 或团队协作建议用项目级配置：进项目根目录，执行
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（不加-g），它会自动追加到repositories数组，不破坏已有私有源
换源后仍卡在 Downloading？必须看 -vvv 日志确认真实请求域名
光看 config 输出没用，得看到网络请求实际打到哪个域名才算数。
- 实测命令：
composer show monolog/monolog -vvv 2>&1 | grep "Downloading"，日志里必须出现mirrors.aliyun.com或mirrors.cloud.tencent.com等镜像域名 - 若仍出现
packagist.org，说明镜像未生效，优先检查repo.packagist键名和项目级repositories覆盖 - 别跳过
composer clear-cache：旧缓存里存着官方源的元数据，Composer 会优先读缓存并尝试从旧地址校验，结果就是卡在 DNS 或 TLS 握手
镜像只加速下载阶段，不解决 Resolving dependencies 卡顿；如果卡在这一步，和镜像无关，要查 minimum-stability 设置、PHP CLI 的 opcache 是否启用、或私有仓库地址是否已下线。
