运行Composer install命令时超时限制的修改方法-composer-PHP中文网

卡在downloading https://就调http-timeout，卡在installing dependencies或报the process timed out就调process-timeout；二者独立生效，只改一个无效：http-timeout控制http请求总时长（dns+tls+下载），默认300秒；process-timeout控制子进程执行时长（git clone等），默认300秒，新版需用环境变量composer_process_timeout全局设置。

运行composer install命令时超时限制的修改方法

卡在 Downloading https:// 就调 http-timeout，卡在 Installing dependencies 或报 The process timed out 就调 process-timeout；二者完全独立，只改一个大概率还是失败。

怎么判断该调哪个 timeout

错误现象直接决定配置方向：

看到 Could not fetch https://repo.packagist.org/packages.json、curl error 28、反复 retry 后失败，或卡在 Downloading https://mirrors.aliyun.com/ ——这是 http-timeout 不够，它管的是 HTTP 请求从 DNS 开始到 body 下载完成的总时长
看到 [RuntimeException] The process "git clone ..." exceeded the timeout、卡在 Installing dependencies 阶段几秒后直接中断——这是 process-timeout 触发，它只杀子进程（如 git、unzip、自定义脚本），和网络下载无关

注意：--timeout=600 这种命令行参数在 Composer 2.2+ 中仅等价于 --process-timeout=600，不改 HTTP 层；旧版甚至可能忽略 --http-timeout。

全局配置的正确写法（避免静默失效）

Composer 2.2+ 对键名、类型、URL 格式极其敏感，错一个就 fallback 到官方源，且不报错：

repo.packagist 必须是单数，repos.packagist 或 repositories.packagist 全无效
type 值必须显式写成 "composer"，不能省略，也不能替换成 URL 或注释
url 必须以 https:// 开头，且末尾必须带 /：https://mirrors.aliyun.com/composer/ ✅，https://mirrors.aliyun.com/composer ❌（会请求 /composer/packages.json，404）

正确命令示例：

composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
composer config -g http-timeout 600
composer config -g process-timeout 1800

验证是否生效，只看这一行输出：composer config -g repo.packagist，结果必须是完整 JSON：{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。

Discussion Composer

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

下载

CI/CD 或 Docker 构建中怎么确保配置生效

容器每次启动都是干净环境，COMPOSER_HOME 未固化会导致全局配置丢失：

必须在构建脚本开头显式执行配置命令，不能只靠本地开发机设置
更稳的做法是放弃全局配置，进项目根目录运行：composer config repo.packagist composer https://mirrors.aliyun.com/composer/（不带 -g），它会安全合并进 composer.json 的 repositories 字段，Git 可追踪，CI 可复现
若项目已有私有仓库配置，别手动编辑 composer.json 的 repositories 字段——容易格式错、漏逗号、破坏 JSON 结构

另外，process-timeout 在新版中全局配置已失效，必须用环境变量：COMPOSER_PROCESS_TIMEOUT=1800（Linux/macOS）或系统级环境变量（Windows）。

为什么调了 timeout 还卡在 github.com

这不是 http-timeout 没起作用，而是底层 socket 连接根本没建立成功——http-timeout 只计「连接建立后」的数据传输阶段，DNS 解析慢、TLS 握手卡住、代理不可用，都会让请求卡在 connect 阶段，永远等不到超时计时开始。

此时要检查：

echo $HTTP_PROXY 和 echo $HTTPS_PROXY 是否设了但实际不可用
是否被公司防火墙拦截，可试 curl -v https://github.com 看卡在哪一步
macOS 用户需刷新 DNS 缓存：sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

真正麻烦的是混合场景：镜像源启用了防盗链、PHP CLI 的 default_socket_timeout（查 php -i | grep default_socket_timeout）仍为默认 60 秒、或 ulimit 限制了打开文件数——这些都比单纯调 timeout 更容易被忽略。