Composer全局镜像配置必须同时满足四要素：键名严格为repo.packagist（单数）、-g参数不可省、type值显式写composer、URL为HTTPS且末尾带/，缺一即静默回退官方源；验证需执行composer config -g repo.packagist输出完整JSON对象。
直接运行 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 就能生效，但 90% 的失败不是网络问题，而是命令写错三个硬性条件——漏掉任意一个，它就静默回退到 packagist.org，不报错、不提示、也不下载镜像。
为什么 composer config -g repo.packagist 总是“看起来成功，实际没用”
这条命令的校验极严格，不是拼对了就行：
-
repo.packagist必须一字不差：写成repos.packagist（多一个 s）、repositories.packagist或mirror，Composer 完全忽略，且不报错 - 中间的
composer是type值，不是可选参数——省略后 Composer 2.0+ 会 fallback 到官方源 -
https://mirrors.aliyun.com/composer/末尾斜杠/不可少：少斜杠会拼出/composerpackages.json，返回 404 或空响应 - 必须带
-g：漏掉就只改当前目录下的composer.json，换项目就失效
怎么验证是否真写进去了
别信“命令没报错”，要亲眼看到结果：
- 运行
composer config -g repo.packagist，输出必须是完整 JSON，形如{"type":"composer","url":"https://mirrors.aliyun.com/composer/"}；空、null、或仍是https://packagist.org都说明失败 - 更可靠的方式是加日志观察：运行
composer install -vvv 2>&1 | grep "Downloading"，确认域名是mirrors.aliyun.com而非packagist.org - 注意：
composer config repo.packagist（无-g）查的是项目级配置，不能用来验证全局是否生效
项目里有 repositories 字段，全局镜像还起作用吗
完全不起作用。Composer 的仓库优先级是硬编码的：项目 composer.json > 全局 ~/.composer/config.json > 默认源。
- 只要项目根目录的
composer.json里定义了"repositories"（哪怕只是空数组[]或{"packagist.org": false}），全局配置就会被跳过 - 想临时绕过项目配置验证镜像？用
--repository-url参数：composer update --repository-url=https://mirrors.aliyun.com/composer/ - 团队协作或 CI 场景下，建议改用项目级配置：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（去掉-g），它会安全合并进composer.json的repositories字段
换源后还是卡在 Resolving dependencies？
镜像只加速下载阶段，对依赖解析过程毫无影响。这时候和网络、镜像完全无关：
-
"php": "^7.4 || ^8.0 || ^8.1"这类宽泛约束会让 Composer 暴力尝试所有版本组合，拖慢解析 -
require-dev里塞了太多未锁定版本的工具（如"phpunit/phpunit": "^10.0"） - 用了大量
dev-main或dev-develop分支依赖 - 真正该做的是收紧 PHP 版本约束、锁定 dev 工具版本、删掉
composer.lock后重装
最常被忽略的一点：换源后必须执行 composer clear-cache，并删掉 vendor/ 和 composer.lock，否则旧 lock 文件里的哈希仍指向 packagist.org，导致 fallback 或校验失败。
