composer config -g repo.packagist 命令没生效是因为三个硬性条件未同时满足：键名必须为单数 repo.packagist、第二个参数必须显式指定为 composer、url 必须是 https 且末尾带斜杠；任一缺失均静默回退官方源，验证需输出完整 json 对象。
composer config -g repo.packagist 命令为什么没生效
命令跑完没报错，但 composer install 还卡在 Loading composer repositories——大概率是配置根本没写进去。它有三个硬性条件，缺一就静默 fallback 到 https://packagist.org：
-
repo.packagist键名必须是单数，写成repos.packagist（多一个 s）或packagist（少repo.）全无效 - 第二个参数必须是
composer，不是https、不是空、不能省略 - URL 必须是 HTTPS + 末尾带斜杠：
https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌（少斜杠会拼出 404 路径）
怎么验证镜像真生效了
别信“执行完就 OK”，composer config -g repo.packagist 输出必须是完整 JSON 对象，例如：
{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}
如果返回空、null、Key "repo.packagist" does not exist，说明配置失败。更可靠的方式是加 -vvv 看实际请求：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
composer require monolog/monolog -vvv 2>&1 | grep "Downloading"- 确认日志里出现的域名是
mirrors.aliyun.com或你配的镜像域名
项目级配置比全局更可靠的实际场景
CI/CD（GitHub Actions）、宝塔（www 用户）、Docker 容器，都读不到你的 ~/.composer/config.json。项目级配置可提交 Git，所有人一致：
- 进项目根目录，运行：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（去掉-g） - 它会往
composer.json的"repositories"字段里安全追加"packagist"子项 - 如果
"repositories"是数组[]，命令会报错；需先手动改成对象{} - 改完删掉
vendor/和composer.lock，再跑composer install（不是update）
换源后还卡在 “Resolving dependencies”？镜像不背这个锅
镜像只加速下载阶段，对依赖解析完全无影响。卡在这里，和网络无关，典型原因是：
-
composer.json里 PHP 版本约束太宽，比如"php": "^7.4 || ^8.0 || ^8.1"，求解器暴力穷举组合 - 某些包声明了大量
conflict或复杂replace规则，拖慢解析 - 本地
composer.lock与新镜像元数据不匹配（尤其换源后没清 lock 文件）
真正容易被忽略的是：全局配置在多人协作或自动化环境中几乎不可靠，而项目级配置一旦写错 repositories 结构，就会覆盖私有源或禁用回退机制——这时候不是慢，是直接失败。
