composer config -g repo.packagist 必须严格满足三个条件才生效：键名必须为单数 repo，type 值必须为 composer，url 必须是 https 且末尾带斜杠；否则静默失效，不报错也不生效。
composer config -g repo.packagist 这条命令必须写对，否则静默失效——不是慢，是根本没走镜像。
为什么 composer config -g repo.packagist 总不生效
它不报错，但也不干活。常见失效场景有三个硬性条件漏掉任意一个：
-
repo.packagist键名必须是单数repo，写成repos.packagist或packagist.org都无效 - 中间那个
composer是type值，不是可选参数，漏掉就 fallback 到https://packagist.org - URL 必须是 HTTPS 且末尾带斜杠：
https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌（少斜杠会拼出/composerpackages.json，404）
验证是否写入成功，只看这一行输出：composer config -g repo.packagist。返回空、null、或仍是 https://packagist.org，说明根本没配进去。
项目级配置比全局更可靠
CI/CD 流水线（如 GitHub Actions）、宝塔面板、Docker 容器里常以 www 或 runner 用户运行，读不到你本地的 ~/.composer/config.json。项目级配置写进 composer.json，Git 可追踪，行为可预期。
- 进项目根目录，执行：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（注意不加-g） - 该命令会自动向
composer.json的repositories字段追加"packagist"条目，不覆盖已有私有源 - 如果
composer.json原本是"repositories": {}，它会转为标准对象格式；如果是"repositories": []，则追加到数组末尾 - 改完务必运行：
composer update --lock，让composer.lock记录新源地址
换镜像后仍卡在 Resolving dependencies
这不是镜像问题，镜像只加速下载环节（Downloading、Fetching package），不参与依赖解析。卡在这里基本是以下原因：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
php版本约束太宽，比如"php": "^7.4 || ^8.0 || ^8.1"，让 Composer 尝试大量组合 -
require-dev里塞了太多工具链（如phpunit、phpstan），大幅增加解空间 - 用了已废弃的
fxp/composer-asset-plugin（常见于老版 Yii2），它绕过 Composer 镜像机制，直连 Bower/NPM 源
这类问题换任何镜像都无效，得收紧约束、拆分 dev 包、或升级到原生 asset 管理方案。
必须用 -vvv 看真实请求 URL
-vvv 不是调试选项，它是唯一能确认“到底走哪个源”的证据。日志里出现 mirrors.aliyun.com 才算真生效。
- 运行：
composer install -vvv 2>&1 | grep "Downloading"，观察 URL 域名 - 临时测试可用性：
composer create-project laravel/laravel test --repository=https://mirrors.aliyun.com/composer/ -vvv - 如果项目级
repositories已存在，它会直接覆盖全局镜像——这是最常被忽略的失效原因
别信感觉，只信日志里打印出的域名。
