composer镜像配置不生效是因为三个硬性条件缺一不可：键名必须为单数repo.packagist、type值必须显式写composer、url必须https且末尾带/；任一错误即静默回退官方源且不报错。
配镜像源不是“换地址就行”，90% 的失败都源于命令写错三个硬性条件——漏 -g、键名写成 repos.packagist（多一个 s）、或 URL 少了末尾斜杠 /。这三处任一出错，Composer 都静默失效，不报错也不提示。
为什么 composer config -g repo.packagist 总是不生效
这条命令看似简单，但漏掉任意一个要素，Composer 就会直接忽略它，继续连 packagist.org：
-
repo.packagist不能写成repos.packagist（多一个 s 就完全无效） - 必须显式写出
composer作为type值，不能省略；省略后 Composer 2.x+ 会 fallback 到默认源 - 镜像 URL 必须以
/结尾，例如https://mirrors.aliyun.com/composer/✅，少斜杠会导致请求路径拼错，返回 404 - 必须用 HTTPS，HTTP 地址在 Composer 2.9+ 中会被拒绝
验证是否写对，只看这一条命令输出：composer config -g repo.packagist。正确结果应为完整 JSON：{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}；返回空、null 或报错，说明没写对。
项目级配置为什么比全局更可靠
全局配置依赖用户环境（比如宝塔里 www 用户读不到 /root/.composer/config.json），而项目级配置写进 composer.json，Git 可追踪、CI 可复现、新人拉代码即生效，且优先级更高：
- 执行
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（不加-g）会自动向composer.json的repositories字段追加条目，前提是原repositories是对象格式（{}），不是数组（[]） - 若
repositories已是数组，该命令会报错，需先手动改为对象结构 - 切勿手写
"packagist.org": false——这会让 Composer 屏蔽基础包校验，导致require失败；正确做法是保留官方源兜底，把镜像放repositories数组首位
换源后依然卡在 Loading composer repositories
这不是网络差，是配置静默失效，连报错都没有。镜像只加速包文件下载（.zip/.tar），不参与依赖解析。如果你发现 composer install 卡在这一步，问题大概率出在：
- 没清缓存：
composer clear-cache - 没删旧文件：必须手动删除
vendor/和composer.lock，再跑composer install；update没用，它照着旧lock文件里的 dist URL 下载 - 项目级配置覆盖了全局设置：只要
composer.json里有repositories字段，无论内容是否有效，Composer 都会优先用它，且不提醒
怎么确认 Composer 真正在用国内镜像
别信配置命令的输出，要看它实际发出去的请求：
- 运行
composer diagnose，找到Repo packagist.org:这一行，后面域名必须是你配的镜像（如mirrors.aliyun.com） - 新建空目录，执行
composer init -n && composer require monolog/monolog -vvv，日志第一行Downloading https://的域名必须匹配镜像地址 - 真实生效的日志特征是类似
Reading packages.json from cache at /https---mirrors-aliyun-com-composer/——路径里出现镜像域名的转义形式，才是真走镜像
最常被忽略的一点：改完配置后，不删 composer.lock 就跑 install，等于白配——锁文件里记录的是旧源地址和哈希，根本不会触发镜像请求。
