composer config -g repo.packagist 命令静默失效，根本原因是键名必须为单数 repo.packagist、type 值必须显式写 composer、url 必须 https 且末尾带 /，三者缺一即回退官方源；验证需输出完整 json 对象。
composer config -g repo.packagist 命令为什么没生效
这条命令静默失败是常态，它不报错、不提示，但实际仍走 https://packagist.org。根本原因只有三个硬性条件没满足：repo.packagist 键名写错（比如 repos.packagist 多了个 s）、漏掉中间的 composer type 值、URL 末尾缺 /。
验证是否真生效，只看这一行输出：composer config -g repo.packagist。正确结果必须是完整 JSON：{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。返回空、null、报 Key not found 或仍是官方地址，说明配置根本没写进去。
-
repo.packagist是固定键名，大小写敏感，不能写成Repo.Packagist或repositories.packagist - 中间的
composer是 type 字段值，不是可选参数，也不能替换成composer.org或省略 - URL 必须以
https://开头，且末尾带/，例如https://mirrors.aliyun.com/composer/✅，少斜杠会拼出/composerpackages.json导致 404
如何安全执行全局镜像切换
直接运行这条命令即可，无需改文件、不依赖脚本：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/。它会自动写入当前用户的 ~/.composer/config.json（Windows 在 %USERPROFILE%\AppData\Roaming\Composer\config.json），优先级高于项目级配置。
常见踩坑点：
- Linux/macOS 权限错误：提示
Permission denied，说明~/.composer目录归属不是当前用户，先运行chown -R $USER ~/.composer - Windows PowerShell 路径解析异常：建议用 CMD 或 Git Bash 执行，避免
/和\混用 - 误用已停用地址：如
https://packagist.phpcomposer.com，curl 会报Could not resolve host - 用了
sudo执行但日常开发用普通用户：配置写进了 root 的配置文件，普通用户读不到
宝塔、CI、Docker 环境下全局配置为何不生效
全局配置只对执行命令的用户生效。宝塔后台默认以 www 用户运行，GitHub Actions 使用 runner 用户，Docker 容器里可能是 www-data 或自定义用户——它们都读不到你终端里个人用户的 ~/.composer/config.json。
临时解决方法是显式切换用户再配：
- 宝塔环境：
sudo -u www composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 确认实际 UID：
whoami或查日志，再针对性执行 - 更稳妥的做法是放弃全局，进项目根目录运行：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（去掉-g），它会安全写入composer.json的repositories字段，Git 可追踪，CI 可复现
换源后依然卡在 Loading composer repositories 怎么办
镜像没被用上，90% 是缓存和旧文件干扰。Composer 优先读本地元数据缓存和 composer.lock 中记录的旧 URL，哪怕你刚配完新源，它仍可能反复请求 packagist.org。
必须按顺序操作：
- 先清缓存：
composer clear-cache - 删掉项目下的
vendor/和composer.lock - 再执行
composer install -vvv，观察日志里是否出现mirrors.aliyun.com - 如果企业网络拦截 HTTPS，临时加
-n跳过证书校验（仅限可信环境）：composer install -n
镜像只加速下载，不解决 Resolving dependencies 卡顿——那属于本地依赖解析问题，和镜像源无关。
