composer镜像配置静默失效的主因是命令未写入配置，必须同时满足三个硬性条件：键名严格为repo.packagist（单数）、显式指定type值composer、url须https且末尾带/；任一缺失即静默回退官方源。
直接执行 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 就能生效，但漏掉任意一个细节都会静默失败——不是没反应，是根本没写进去。
为什么 composer config -g repo.packagist 总不生效
这不是网络问题，也不是镜像站挂了，而是 Composer 2.x/3.x 在配置非法时选择静默回退到 https://packagist.org，连 warning 都不抛。常见硬伤有三个：
-
repo.packagist键名写成repos.packagist（多一个 s）或packagist.org—— 只有单数repo.packagist是合法键名 - 漏掉
composer这个 type 值：命令里必须显式写出composer，不能省略，它不是注释也不是默认值 - URL 缺末尾斜杠：
https://mirrors.aliyun.com/composer❌ 会拼成/composerpackages.json导致 404；https://mirrors.aliyun.com/composer/✅ 才正确
验证是否真写进去了，别信“命令没报错”
执行完命令后，立刻运行：
composer config -g repo.packagist
正确输出必须是完整 JSON 对象：
{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}
如果返回空、null、Key "repo.packagist" does not exist，或者还是 https://packagist.org，说明配置压根没写成功。可能原因包括：
- 你在 Git Bash 里执行，但路径解析异常（换 PowerShell 或 CMD 重试）
- Windows 下 OneDrive 或杀毒软件锁住了
%APPDATA%\Composer\config.json - 你用了
sudo执行，但日常开发用的是普通用户账号
项目级配置比全局更可靠，尤其在 CI 和 Docker 中
全局配置在宝塔、GitHub Actions、Docker 容器里大概率读不到——因为它们不是以你当前用户身份运行的。这时候项目级更稳：
- 进项目根目录，运行：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/ - 这条命令会向
composer.json的repositories字段写入，但注意："repositories": {}必须是对象，不能是数组（否则失败） - 改完务必运行：
composer update --lock，否则composer.lock里仍记着官方源地址
别手写 "packagist.org": false —— 这会彻底禁用回退机制，镜像临时不可用时直接失败。
换源后还卡在 “Loading composer repositories” 怎么定位
这不是镜像没生效，而是请求压根没发到镜像站。最常见源头是：
- 项目
composer.json里已有repositories字段，且包含"packagist.org": false或其他自定义源，它会覆盖全局设置 - 你之前用
--repository参数跑过命令，而该参数优先级最高，会完全忽略全局和项目配置 - 运行
composer diagnose，看Repo.packagist.org行显示的是不是你的镜像地址；再加-vvv跑一次composer install，观察实际请求域名是不是mirrors.aliyun.com
真正容易被忽略的是：全局配置只对“未显式声明 repositories 的项目”起效；一旦项目里写了 repositories，就得在里面手动配镜像，或者删掉整个字段再靠全局兜底。
