直接执行 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 即可生效，但漏 -g、键名错（应为单数 repo.packagist）、url 缺末尾 / 或漏 composer 类型值均会静默失效；验证需查 composer config -g repo.packagist 输出、composer diagnose 的 repo 行及 -vvv 日志中的实际下载 url。
直接执行 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 就能生效，但漏掉 -g、写错键名、URL 缺末尾 / 或漏掉 composer 类型值，都会静默失败——不是网络慢，是根本没走镜像。
为什么 composer config -g repo.packagist 总不生效？
Composer 2.x 内部硬编码只识别 repo.packagist（单数、全小写、无 s），写成 repos.packagist 或 packagist.org 都会存进无效字段，命令不报错，但 composer install 仍走官方源。
-
-g必须带上，否则只改当前项目composer.json，换目录就失效 -
repo.packagist是固定键名，拼错大小写或加s都无效 -
composer是必需的type值，不是注释，漏掉就 fallback 到packagist.org - URL 必须以
https://开头且末尾带/，少斜杠会导致请求路径拼成/composerpackages.json直接 404
怎么验证镜像是否真在用？
别信“好像快了”，要查实际配置和网络行为：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（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覆盖了 - 删掉
vendor和composer.lock，再跑composer install -vvv，观察日志里下载 URL 是否含mirrors.aliyun.com
项目级配置比全局更可靠？
团队协作或 CI 环境里，全局配置容易被覆盖或权限错位（比如宝塔面板用 www 用户跑命令，但 -g 写的是 root 的配置）。项目级配置可 Git 跟踪、行为一致：
- 进项目根目录，去掉
-g执行：composer config repo.packagist composer https://mirrors.aliyun.com/composer/ - 它会往
composer.json的repositories字段里安全合并，不会覆盖已有私有源（前提是原repositories是对象，不是数组） - 如果项目已有
"repositories": {"packagist.org": false}，得先删掉该字段，再补一句composer clear-cache，否则旧缓存仍可能触发packagist.org请求
最常被忽略的是 composer.lock 文件里的 dist URL 还指向原始源——哪怕镜像已生效，composer install 仍会先尝试旧地址。必须执行 composer update --lock 强制刷新 lock 文件中的下载链接，否则卡在 installing xxx (v1.2.3) 不是镜像没切对，而是 lock 文件没更新。
