命令总不生效是因为漏加-g、键名写成repos.packagist或url缺末尾/，三者任一出错均静默回退官方源；正确写法为composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，验证需输出完整json对象。
composer config -g repo.packagist 命令为什么总不生效
不是网络问题，而是命令写错了三个硬性条件，Composer 2.x 会静默 fallback 到官方源，连错误都不报。
-
-g缺不得：漏掉就只改当前项目composer.json，换目录或新开终端就失效 - 键名必须是
repo.packagist（单数repo，不是repos.packagist或packagist.org） -
composer是必填的type值，不是注释——省略后 Composer 直接忽略该配置 - URL 必须以
https://开头，且末尾带/；少斜杠会拼出/composerpackages.json导致 404
验证是否成功：运行 composer config -g repo.packagist，正确输出应为类似 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。返回空、null 或报错，说明没配对。
项目级配置比全局更可靠，但要注意 repositories 结构
全局配置在 CI、宝塔、Docker 等场景下常因用户权限或环境隔离而读不到；项目级配置写进 composer.json，可 Git 提交，团队行为一致。
- 进项目根目录执行：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（去掉-g） - 它会安全写入
"repositories": { "packagist": { ... } }，不覆盖已有私有源——前提是原repositories是对象（{}），不是数组（[]） - 如果
composer.json里已有"repositories": []，命令会失败；需先手动改成"repositories": {}再运行 - 若已存在
"packagist.org": false或"packagist": false，镜像配置会被彻底屏蔽，得同步删掉这行
换镜像后 still stuck at “Loading composer repositories” 怎么排查
这不是镜像没响应，而是请求根本没发出去——大概率被更高优先级的配置或禁用语句拦截了。
- 分别运行
composer config -g repo.packagist和composer config repo.packagist，看哪一层实际生效 - 检查
composer.json是否含"packagist.org": false、"packagist": false或"repositories": []（空数组） - 临时验证镜像服务是否可达：
curl -I https://mirrors.aliyun.com/composer/packages.json，返回200 OK才算正常 - Windows 用户注意：PowerShell 和 CMD 的环境变量不共享，改完配置后务必新开终端再验证
宝塔、CI、Docker 里 composer install 还是慢？重点查执行用户
全局配置写在 ~/.composer/config.json，但不同环境用的不是同一个用户。
- 宝塔后台执行时默认是
www用户，root下配的全局配置它读不到 - CI 流水线常用
runner用户，Docker 构建容器里甚至没有~/.composer目录 - 查真实执行用户：
ps aux | grep composer或看日志里的 UID - 切到对应用户重配：
sudo -u www composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
项目级配置在这类场景下几乎无脑可用，只要 composer.json 里有正确的 repositories，就不依赖用户家目录。
