composer install卡在“loading composer repositories”是因默认直连被阻断的packagist.org，非网络差；镜像不生效主因是config命令漏type参数、url缺末尾斜杠或项目级repositories覆盖全局配置。
为什么composer install卡在“Loading composer repositories”？
这不是网络差，是还在连packagist.org——默认源在国内解析慢、连接不稳定，常卡住十几分钟甚至超时。镜像不生效，90% 是命令写错或被覆盖，不是源本身问题。
-
composer config -g repo.packagist必须带composer类型参数，漏掉就静默 fallback 到官方源 - 镜像 URL 必须以
/结尾，比如https://mirrors.aliyun.com/composer/✅，少斜杠会拼出 404 路径 - 项目根目录下有
composer.json且含"repositories": [...]，全局配置直接失效 - 执行后别只信
composer config -g repo.packagist输出，要跑composer diagnose看Repo packagist.org:后面是不是你的镜像域名
怎么让镜像真正用起来，而不是“配了等于没配”？
光改配置文件不够，Composer 会缓存旧元数据、沿用旧 composer.lock 里的 dist URL，导致仍走原始 GitHub 地址下载。
- 先清缓存：
composer clear-cache - 删干净：
rm -rf vendor/ composer.lock（仅首次配镜像时必须） - 重装依赖：
composer install -vvv 2>&1 | grep -i "mirrors\|Downloading"，确认日志里出现镜像域名 - 若仍见
packagist.org或api.github.com，说明composer.lock没删干净，或项目级repositories覆盖了全局设置
composer require 还是慢？这三类情况镜像完全不生效
镜像只加速 packagist.org 上的 PHP 包，其他来源不受影响，容易误判为“镜像没用”。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 依赖里含 GitHub 直链（如
"type": "package"+"dist"指向api.github.com），镜像无效 -
composer.lock中的dist.url仍是原始地址，需删 lock 文件后重装 - 安装
ext-*扩展（如ext-redis），实际由phpize编译，和镜像无关，慢是本地编译耗时
项目级配置比全局更可靠，但要注意写法细节
团队协作或 CI/CD 场景下，项目级配置可被 Git 跟踪、避免权限问题，但必须按 Composer 规则写，否则 JSON 格式错误或优先级错乱。
- 进项目根目录，运行：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（去掉-g） - 它会在
composer.json顶层写入"repositories"字段，key 固定为"packagist"，不会覆盖已有私有源 - 如果原
composer.json已有"repositories": []数组，别手动覆盖，用命令追加；否则可能误删私有包源 - 务必显式禁用默认源：在
repositories数组首位加{"packagist": false}，再插入镜像对象，否则 Composer 可能回退到官方源
最易被忽略的是：镜像只解决下载速度，不解决 Resolving dependencies 卡顿。如果卡在这里，问题在 composer.json 的版本约束太宽、dev 分支太多，或 PHP 版本不匹配，跟镜像无关。
