composer config -g repo.packagist 没效果是因为键名必须为单数 repo.packagist、-g 不可省略、中间 composer 是必需 type 值、URL 必须 HTTPS 且末尾带 /，任一缺失即静默回退官方源；验证需输出完整 JSON 对象。
直接执行 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 就能生效，但漏掉 -g、写错键名、缺 composer 类型值、URL 少末尾 / 中任意一项，都会静默回退到官方源——不是慢，是根本没走镜像。
为什么 composer config -g repo.packagist 总没效果？
Composer 2.x 硬编码只认 repo.packagist（单数、全小写、无 s），写成 repos.packagist 或 packagist.org 会存进无效字段，查不到也用不上。
-
-g必须带上，否则只改当前项目composer.json，换目录就失效 -
composer是必需的type值，不是注释；漏掉它，Composer 就 fallback 到默认源 - URL 必须以
https://开头且以/结尾，否则请求路径拼成/composerpackages.json直接 404 - 验证是否成功：运行
composer config -g repo.packagist，输出必须是类似{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}的完整 JSON 对象
composer install 还卡在 loading package information？
镜像已生效，但 composer.lock 里记录的仍是 packagist.org 的 dist URL，Composer 会先尝试走这个地址。
- 执行
composer clear-cache清掉旧元数据缓存 - 再运行
composer update --lock强制刷新 lock 文件中的下载链接 - 检查代理残留：
env | grep -i proxy，Composer 不自动绕过代理 - DNS 污染时，
ping mirrors.aliyun.com若解析异常，换 DNS 如114.114.114.114
项目级配置比全局更可靠？
CI 或团队协作场景下，全局配置容易被覆盖（比如宝塔面板用 www 用户跑命令，但 -g 写的是 root 的配置），此时应改项目级配置并提交到 Git。
- 进项目根目录，去掉
-g执行：composer config repo.packagist composer https://mirrors.aliyun.com/composer/ - 它会往
composer.json的repositories字段里安全合并，前提是原字段为对象格式（如"repositories": {}） - 如果原
repositories是数组（如"repositories": [{}]），命令会失败，需先手动转成对象再操作 - 已有
"packagist.org": false这类禁用项，得先删掉，再执行composer clear-cache
最常被忽略的是 composer.lock 里的 dist URL 和本地缓存的组合影响——只切镜像不更新 lock，依赖还是从旧地址拉；只清缓存不刷新 lock，新镜像也用不上。
