Composer代理配置解决卡顿烦恼指南-composer-PHP中文网

composer卡在loading或downloading阶段，90%因镜像未生效或代理缺失：必须严格配置-g repo.packagist、type=composer、https末尾带斜杠；https代理需单独设https-proxy；已有lock文件须composer update --lock重写dist.url。

composer代理配置解决卡顿烦恼指南

Composer 卡在 Loading composer repositories 或 Downloading 阶段，90% 是代理没配对或镜像没生效——不是网络差，是请求根本没发到国内源或代理没走通。

为什么只配 `http-proxy` 还是卡住？

Composer 对 HTTP 和 HTTPS 请求走不同代理字段：前者用 http-proxy，后者必须用 https-proxy（哪怕值是 http://127.0.0.1:7890）。漏掉 https-proxy，所有仓库元数据和 dist 包下载都会 fallback 直连，日志里只显示超时或 TLS 错误，不报代理相关提示。

常见错误现象：

file_get_contents(): SSL operation failed → 代理未转发 HTTPS 流量，或本地 CA 不被信任
Connection refused → 代理进程未运行、端口错、防火墙拦截
命令执行成功但 composer install -v 最后请求仍是 https://packagist.org/... → https-proxy 没写进去

验证是否生效：

composer config -g --list | grep -E "(http|https)-proxy"

输出必须同时包含两行，且 URL 格式为 http://user:pass@127.0.0.1:7890（密码含 @ 或 / 要先 rawurlencode）。

`composer config -g repo.packagist` 命令静默失效的四大硬伤

这条命令极易“看似成功，实则无效”，因为 Composer 2.2+ 遇到配置错误会静默 fallback 到官方源，不报错也不提醒。

必须同时满足四点，缺一不可：

Discussion Composer

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

下载

带 -g 参数，否则只改当前项目，CI/CD 环境读不到
键名是 repo.packagist（单数），写成 repos.packagist 或 repositories.packagist 全部忽略
中间显式传入 composer 作为 type 值，漏掉就当没配
URL 必须是 HTTPS + 末尾带斜杠：https://mirrors.aliyun.com/composer/ ✅，少斜杠会拼出 /composerpackages.json 导致 404

验证是否真写进去了：

composer config -g repo.packagist

输出必须是完整 JSON，例如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。空、null、字符串 URL 或仍为 https://packagist.org，说明根本没写进 ~/.composer/config.json。

CI/CD、Docker、宝塔里全局配置为啥不起作用？

因为 composer config -g 写的是当前用户（比如你本地的 root 或 admin）的 ~/.composer/config.json，而 CI runner、Docker 容器、宝塔后台常以 www-data、runner 或其他受限用户身份运行，压根读不到你的配置。

稳解是项目级配置：

进项目根目录，执行：

composer config repo.packagist composer https://mirrors.aliyun.com/composer/

（注意：不加 -g）

该命令会安全写入 composer.json 的 "repositories" 字段，key 必须是 "packagist"，不能改成 "aliyun" 等别名
已有 "repositories" 字段时自动合并，避免手动编辑 JSON 出现逗号或引号错误
提交 composer.json 后，所有协作者和 CI 作业行为一致

换源后仍卡？别信“命令跑完了”，打开 composer.lock，找任意一个包的 dist.url，必须是镜像域名下的路径，例如 https://mirrors.aliyun.com/composer/dists/...。

换源后还卡在 `Resolving dependencies`？那和网络无关

镜像只加速下载环节（Downloading、Fetching package），不解决依赖求解慢的问题。如果卡在这里超过 10 秒，重点排查：

php 版本约束太宽，例如 "php": "^7.4 || ^8.0"，触发大量版本兼容性检查
Xdebug 启用中：会让解析慢 5–10 倍，临时禁用：php -d xdebug.mode=off $(which composer) install
内存不足：默认 128M 不够，加环境变量：COMPOSER_MEMORY_LIMIT=-1
platform 配置与实际 PHP 版本不匹配，比如 "php": "7.4" 却在 PHP 8.2 上运行，触发降级查找逻辑

真正容易被忽略的是：已有 composer.lock 的项目，即使换了镜像，Composer 仍会优先尝试 lock 文件里记录的原始 dist.url（通常是 packagist.org 的地址），失败后才 fallback——而 fallback 不保证成功。必须执行 composer update --lock 强制重写所有 dist.url 字段。