Composer install卡在Downloading或Loading repositories，基本可断定未成功切换国内镜像源；常见失效原因包括键名写错（如repos.packagist）、漏掉type参数composer、URL末尾缺斜杠，三者任一出错均静默回退至packagist.org。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

composer install 卡在 Downloading... 或 Loading composer repositories，基本可以断定是默认源 https://packagist.org 未被替换——不是网络差，是根本没走国内镜像。

为什么 composer config -g repo.packagist 常静默失效

这条命令看似简单，但三处细节错任何一处都会 fallback 回官方源，且不报错：

• repo.packagist 不能写成 repos.packagist（多一个 s 就完全忽略）
• 中间必须带 composer 这个 type 参数：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ ✅；漏掉 composer 就无效 ❌
• URL 必须是 HTTPS + 末尾带斜杠：https://mirrors.aliyun.com/composer/ ✅；https://mirrors.aliyun.com/composer ❌（少斜杠会导致 404 或空响应）

验证是否生效：运行 composer config -g repo.packagist，输出应为完整 JSON，形如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。若为空、null 或仍显示 https://packagist.org，说明没写进去。

项目级配置比全局更可靠，但别用命令覆盖 repositories

全局配置在宝塔、CI、Docker 等多用户环境下极易失效（比如宝塔以 www 用户运行，但你配的是 root 的 config.json）。项目级配置可提交到 Git，所有人行为一致。

• 已有私有源或自定义 repositories？别执行 composer config repo.packagist ...（它会全量替换整个 repositories 字段，清空你原有的 Git 源或 Satis 源）
• 正确做法：手动编辑 composer.json，在 repositories 数组里追加一项：{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}
• 必须在 composer.json 根节点添加 "packagist.org": false（注意：不是放在 repositories 里面），否则 Composer 仍会 fallback 到官方源
• 改完后删掉 vendor/ 和 composer.lock，再跑 composer install（不是 update）

-vvv 是唯一能确认镜像是否命中的方式

光看命令执行完没报错没用。真正卡住时，要靠日志定位：

• 执行 composer require monolog/monolog -vvv，观察终端输出的 HTTP 请求地址
• 重点确认：请求 URL 是否含 mirrors.aliyun.com 或你配的镜像域名
• 如果出现 Connection timed out 或 curl error 28，说明 DNS 或本地网络不通，不是 Composer 配置问题
• 如果日志里反复出现 GET https://packagist.org/packages.json，说明 "packagist.org": false 没生效，或 repo.packagist 配置失败

镜像只是代理，不是魔法——ping mirrors.aliyun.com 和 curl -I https://mirrors.aliyun.com/composer/packages.json 能更快判断是配置问题还是底层网络问题。

Resolving dependencies 卡住跟镜像完全无关

这个阶段不发任何网络请求，纯本地计算。常见原因：

• "minimum-stability": "dev" 或大量 "*" 版本约束，导致求解器穷举爆炸
• PHP 版本约束太宽（如 "php": "^7.4 || ^8.0"），尤其搭配 require-dev 包时
• 启用了已废弃插件（如 fxp/composer-asset-plugin），它绕过镜像直接连 Bower/NPM
• clear-cache 没执行，旧缓存里的元数据还在干扰解析

此时换镜像毫无作用。先跑 composer install -vvv 看卡点，再收紧版本、禁用 xdebug、删缓存。 实际部署时最容易被忽略的，是“谁在执行命令”和“缓存是否清干净”。宝塔里跑安装脚本，往往用的是 www 用户，而你配的是 root 的全局配置；缓存不清，Composer 会优先读旧元数据，哪怕镜像已配好也照样卡。