composer config -g repo.packagist 命令总不生效是因为必须同时满足四个硬性条件：键名严格为repo.packagist（单数、小写、无s）、必须带-g参数、第三参数composer（type值）不可省略、URL须以https://开头且末尾带/，任一缺失均静默回退官方源；验证需输出完整JSON对象且-vvv日志中GET请求指向镜像域名。
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 这条命令就能生效，但漏掉 -g、写错键名、少末尾斜杠或漏 composer 类型值，都会静默失败——不是网络慢，是根本没走阿里源。
为什么 composer config -g repo.packagist 总不生效？
Composer 2.x（当前主流）硬编码只认 repo.packagist 这个键名，拼成 repos.packagist、packagist.org 或大小写混用（如 Repo.Packagist），配置会存进无效字段，命令不报错，但 composer install 仍走 https://packagist.org。
-
-g必须带上，否则只改当前项目composer.json，换目录就失效 -
composer是必需的type值，不是可选参数，漏掉就 fallback 到官方源 - URL 必须以
https://开头，且末尾带/；写成https://mirrors.aliyun.com/composer（少斜杠）会导致请求路径拼成/composerpackages.json，直接 404 - 别手写
~/.composer/config.json，容易 JSON 格式错误，导致file_get_contents(): Failed to open stream
怎么验证阿里源真在用？
别信“好像快了”，要查三处：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 运行
composer config -g repo.packagist，输出应为{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} - 运行
composer diagnose，看 “Repo” 行是否显示阿里云地址；若仍是https://packagist.org，说明被项目级repositories覆盖了 - 跑一次
composer install -vvv，在日志里搜Downloading，域名必须是mirrors.aliyun.com—— 这才是最终确认
项目级配置比全局更可靠
全局配置在 CI、宝塔面板、多用户环境里极易出问题：比如宝塔用 www 用户执行命令，但 -g 写的是 root 的配置；或者团队成员没配镜像，composer.lock hash 就不一致。
- 进项目根目录，去掉
-g执行：composer config repo.packagist composer https://mirrors.aliyun.com/composer/ - 它会往
composer.json的repositories字段安全合并，key 固定为"packagist"，不覆盖已有私有源（前提是原repositories是对象，不是数组） - 如果项目已有
"repositories": {"packagist.org": false}，得先删掉该字段，再执行composer clear-cache，否则缓存仍触发官方源请求
换源后还是卡在 Loading composer repositories？
这不是镜像问题，而是 Composer 在解析依赖时卡住，常见原因：
-
composer.lock里硬编码了原始 dist URL，哪怕镜像已生效，composer install仍会先试旧地址 —— 必须执行composer update --lock刷新 - 镜像同步有延迟（阿里云通常 5–10 分钟），刚发布的新包可能还没同步，等一会儿再试
- 启用了
minimum-stability: dev或含大量私有包，会触发深度递归分析，和镜像无关，得查本地 PHP 环境或依赖树 - 某些包（如 GitHub 源、私有 Git 仓库）不受镜像影响，日志里出现
github.com是正常行为，不是镜像失效
composer.lock 文件里残留的原始 dist 地址，以及项目级 repositories 配置对全局设置的静默覆盖。这两点不处理，换再快的镜像也白搭。 
