composer config -g repo.packagist 命令必须同时满足四个条件才能生效：键名严格为 repo.packagist（单数）、显式指定 composer 作为 type 值、url 以 https:// 开头且末尾带 /、必须加 -g 全局标志，缺一即静默回退至官方源。
composer config -g repo.packagist 命令必须带这四个要素
直接执行 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 就能生效，但漏掉任意一个都会静默失败——命令不报错，但后续 composer install 仍连 packagist.org。
-
repo.packagist是固定键名，不能写成repos.packagist（多一个 s）、packagist.org或mirror -
composer是必需的 type 值，不是可选参数，也不能替换成https或留空 - URL 必须以
https://开头，且末尾带/（https://mirrors.aliyun.com/composer/✅，少斜杠会拼出/packages.json导致 404） -
-g参数不可省略，否则只改当前目录下的composer.json，换项目就失效
权限错误时先修复 ~/.composer 所有权
如果提示 Permission denied，说明当前用户对 ~/.composer/config.json 没有写权限，常见于用 sudo 安装过 Composer 或 Homebrew 权限混乱的情况。
- 运行
chown -R $(whoami) ~/.composer修复归属 - 千万别用
sudo composer config -g，否则配置写进/root/.composer/config.json，普通用户和 Web 服务（如 PHP-FPM）根本读不到 - 验证路径是否正确：执行
composer config --list --global，看 “Global configuration file” 行是否指向你家目录下的.composer/config.json
为什么换了镜像还是卡在 Loading repositories？
最常被忽略的一步：composer clear-cache 没执行。缓存里存着旧的 packages.json 和元数据，Composer 会优先读缓存，哪怕源已改，它仍试图从 packagist.org 拉校验信息，结果卡在 DNS 或 TLS 握手。
- 删掉
vendor/和composer.lock再试composer install——旧composer.lock里硬编码了 dist URL，不清理就绕过镜像 - 检查项目级是否覆盖：进项目根目录运行
composer config --list | grep repositories，有输出说明composer.json里写了"repositories"字段，优先级高于全局 - 运行
composer diagnose，看 “Repo.packagist.org” 行是否显示镜像地址；若仍是https://packagist.org，说明被项目配置或缓存干扰
验证镜像是否真在用，别信“好像快了”
不能只看 composer config -g repo.packagist 输出，要确认网络请求实际发到了镜像域名上。
- 新建空目录，执行
composer init -n && composer require monolog/monolog --no-install -vvv 2>&1 | grep "GET https" - 看到类似
GET https://mirrors.aliyun.com/composer/packages.json才算真正生效 - 若出现
Could not resolve host: mirrors.aliyun.com，不是配置问题，是 DNS、公司防火墙或代理拦截，需单独排查网络层 - 清华旧镜像
packagist.phpcomposer.com已下线，继续用会报错，推荐阿里云或腾讯云镜像
composer.lock 是否重建、缓存是否清空、以及 repo.packagist 键名是否一字不差——这三个点任何一个出错，都会让整个配置变成“看起来设了，其实没走”。
