必须配国内镜像源，否则composer install卡在Downloading是常态；需执行composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，并严格满足键名、type值及URL末尾斜杠三要素，缺一则静默回退官方源。

composer install 卡在 Downloading 阶段，不是你网络差，而是默认连的是欧洲的 packagist.org —— DNS 解析慢、TLS 握手不稳定、CDN 节点少，还受防火墙干扰。换镜像不是“试试看”，是必须做的第一步，且必须配对、配全、配准。

怎么确认并正确设置全局中文镜像

执行这条命令即可生效（推荐阿里云源）：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/

它有三个硬性要求，缺一即静默失效（不报错、不提示、照连官方源）：

• 键名必须是 repo.packagist（不是 repos.packagist、mirror 或其他变体）
• 中间的 composer 是必填的 type 值，漏掉会 fallback 到默认源
• URL 必须是 HTTPS 且以 / 结尾：https://mirrors.aliyun.com/composer/ ✅，少斜杠会拼出错误路径返回 404

设完立刻验证：composer config -g repo.packagist 输出应为完整 URL 或 JSON 对象；空、null 或仍显示 https://packagist.org 说明根本没生效。

为什么换了镜像还是卡在 Downloading

镜像只加速元数据（packages.json）和 dist ZIP 包的下载，但实际请求是否真打到镜像，得看日志：

Discussion Composer

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

下载

• composer install -vvv 2>&1 | grep "Downloading" —— 日志里必须出现 mirrors.aliyun.com 或 mirrors.tuna.tsinghua.edu.cn 才算真走镜像
• 项目级 repositories 配置会直接覆盖全局镜像，检查 composer.json 顶层是否有 "repositories" 字段，尤其注意是否含 "packagist.org": false 这类禁用项
• 旧缓存里存着 packagist.org 的元数据，Composer 会优先读缓存并尝试从旧地址校验——结果就是卡在 DNS 或 TLS 握手。必须先运行 composer clear-cache，再删掉 vendor/ 和 composer.lock，最后用 composer install --no-cache 强制走新源

GitHub zip 包仍然直连，怎么绕过

配了镜像但日志里反复出现 Downloading https://api.github.com/ 或 https://codeload.github.com/？这是因为镜像源只代理元数据，不托管 ZIP 包。解决思路不是换 packagist 镜像，而是绕过 GitHub 下载路径：

• 临时加 --repository 参数只影响元数据获取环节，对已锁在 composer.lock 中的 dist.url 完全无效；若 lock 文件里记录的是 GitHub 地址，必须先删 lock 再跑 install
• 企业级方案：部署 satis 或 toran proxy 把 GitHub zip 缓存到内网；个人开发更推荐用 ghproxy.com 类型的反向代理（如 https://ghproxy.com/https://github.com/xxx/yyy/archive/refs/tags/v1.0.0.zip）
• 某些私有包硬编码了 GitHub URL（比如 "dist": {"url": "https://github.com/..."}），这类请求绕不开镜像，需配 github-oauth.github.com Token 或改用 Gitee zip 地址

Resolving dependencies 卡住，跟镜像无关

这个阶段不走网络，但严重受 PHP 环境和依赖结构影响。常见真实瓶颈：

• COMPOSER_MEMORY_LIMIT=-1 临时提高内存限制：默认 128M 在解析复杂依赖图时经常不够
• Xdebug 启用中会让 Resolving dependencies 慢 5–10 倍，用 php -d xdebug.mode=off $(which composer) install 临时禁用
• platform 配置与实际 PHP 版本不匹配（如 "php": "7.4" 却在 PHP 8.2 上运行），触发降级查找逻辑
• composer.lock 里残留已下线包的引用，删掉 vendor/ 和 composer.lock 再重装

最常被忽略的一点：镜像配置只是解决「下载慢」，但一旦卡在解析阶段，再快的镜像也无济于事。得盯紧 -vvv 日志里到底是卡在哪一行，而不是盲目换源或调参数。