答案是阿里云镜像最稳因同步延迟低（1–3分钟）、CDN广、HTTPS一致且兼容Composer 2.9.6；config -g失效主因是漏-g、键名错（如repos.packagist）、缺type值composer、URL少尾斜杠或用HTTP，任一错误均静默回退官方源。
阿里云镜像 https://mirrors.aliyun.com/composer/ 是当前最稳的选择，不是因为单次测速快，而是同步延迟低（通常 1–3 分钟）、CDN 覆盖广、HTTPS 响应一致，且对 Composer 2.9.6 兼容性兜底到位。
为什么 composer config -g repo.packagist 总不生效？
根本原因不是网络被墙，而是命令漏了关键要素，Composer 2.2+ 会静默回退到官方源，不报错也不提示：
-
-g缺失：只改当前项目，换目录就失效 - 键名写成
repos.packagist（多一个 s）或packagist.org：配置写进无效字段 -
type值没显式写composer：缺省时 fallback 到官方源 - URL 少了末尾斜杠，比如写成
https://mirrors.aliyun.com/composer：请求路径变成/composerpackages.json，404 卡住 - 用了 HTTP 协议：Composer 2.2+ 默认禁用非 HTTPS 源
验证是否成功，只看 composer config -g repo.packagist 输出——必须是完整 JSON 对象，形如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。空、null 或字符串都说明失败。
项目级配置为什么比全局更可靠？
团队协作和 CI 环境里，全局配置容易被绕过或权限不一致：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- CI 流水线常用
www-data或runner用户执行，但composer config -g写的是当前登录用户的配置 - 不同成员本地镜像不一致，导致
composer.lock的 hash 不同，引发冲突 - 某些项目
composer.json里写了"packagist.org": false，会直接屏蔽全局镜像
推荐进项目根目录运行：composer config repo.packagist composer https://mirrors.aliyun.com/composer/。它会安全追加到 repositories 字段，key 固定为 "packagist"，不覆盖已有私有源。提交 Git 后，所有环境行为一致。
换源后仍卡在 Loading composer repositories 怎么办？
这不是镜像慢，而是 Composer 还在读旧缓存或旧 composer.lock 里的元数据地址：
- 先执行
composer clear-cache清掉本地缓存 - 删掉项目下的
vendor/和composer.lock - 再跑
composer install -vvv，观察日志里是否出现mirrors.aliyun.com；如果还看到packagist.org，说明配置或清理不到位 - 注意：项目级
repositories字段一旦存在，会完全覆盖全局设置，且不报错——检查composer.json是否误带了旧源
生产部署时哪些细节最容易被忽略？
镜像只是第一步，真正影响稳定性的是后续环节：
-
composer.lock必须随代码一起提交，否则 Docker 构建时只 COPY 了composer.json，install就会重新解析依赖，结果不可控 - 部署命令必须加
--no-dev --no-scripts --no-autoloader，避免脚本在无权限环境失败中断流程 - 之后单独执行
composer dump-autoload -o，而不是让install自动触发——可控、可重试、可捕获错误 - ECS 或内网服务器建议用阿里云内网地址（如
http://mirrors.cloud.aliyuncs.com/composer/），避免走公网增加延迟和流量成本
