Composer安装超时需区分http-timeout（控制HTTP请求）和process-timeout（控制本地子进程），二者独立配置，混用或漏配均导致失败；http-timeout解决下载卡顿，process-timeout解决脚本执行超时，且process-timeout最大有效值为7200秒。
Composer安装超时不是“等不够久”，而是你改错了地方或只改了一半——process-timeout 和 http-timeout 是两套独立机制，卡在不同环节，混用或漏配一个，照样失败。
卡在 Downloading https://xxx？该调 http-timeout
典型现象是报 Could not fetch https://repo.packagist.org/packages.json、curl error 28，或者反复重试后中断。这不是 Composer 本身慢，是 PHP 的 cURL 层等不及 DNS 解析、TLS 握手或首字节响应。
-
http-timeout控制所有 HTTP 请求（拉元数据、下 ZIP 包）的单次等待上限，默认 300 秒 - 项目级生效：
composer config http-timeout 600，写入当前composer.json的config段 - 全局生效：
composer config --global http-timeout 600（影响所有项目） - 临时覆盖优先级最高：
COMPOSER_HTTP_TIMEOUT=600 composer install - 注意：
php -i | grep default_socket_timeout查 CLI 模式下的底层 socket 超时，若值太小（如 60），也会提前掐断——可临时绕过：php -d default_socket_timeout=600 $(which composer) install
卡在 Installing dependencies 或报 The process timed out？该调 process-timeout
错误里明确含 [RuntimeException] The process timed out.，加 -v 能看到最后卡在 git clone、unzip 或某个 post-install-cmd 脚本上。这和网络无关，是本地子进程执行太久被杀。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
process-timeout控制整个命令生命周期（含解压、脚本执行），默认 300 秒 - 新版 Composer 中，
composer config --global process-timeout已失效，别信老教程 - 真正有效的全局方式是环境变量：
export COMPOSER_PROCESS_TIMEOUT=1800（Linux/macOS）或 Windows 系统变量 - 项目级最安全：
composer config process-timeout 1800（写入当前项目配置） - 临时调试：
composer install --process-timeout=1800或COMPOSER_PROCESS_TIMEOUT=1800 composer update - 设为 0 表示禁用检查，但不推荐——真遇到 Git 不可达或脚本死锁，会无限挂起
换镜像源但还是超时？这些坑常被忽略
换源是治本之策，但配错就等于没换。阿里云镜像地址必须是 https://mirrors.aliyun.com/composer（末尾不能带斜杠），否则返回 404；且 repo.packagist 是单值字段，重复执行 composer config -g repo.packagist 会覆盖前一次，不会叠加。
- 验证是否生效：
composer config -g repo.packagist输出应明确含国内域名 - 项目
composer.json中若硬编码了repositories字段，它优先级高于全局配置——已下线的私有源会导致逐个超时重试 - 镜像只加速
dist（ZIP/TAR），对prefer-source: true或 SSH 私有仓库完全无效，此时 Composer 会 fallback 直连 - CI/CD 中务必显式设置
COMPOSER_HOME，否则容器每次重启，全局配置就丢了 - 某些 Docker 基础镜像自带低 timeout 配置，构建前先跑
composer config -g process-timeout 7200再装包，比后期修复更可靠
process-timeout 超过 7200 秒会被强制回退到 300 秒
这不是警告，是硬编码限制：Composer 会主动忽略大于 7200 的值，直接 fallback 到默认 300 秒。所以设成 24 小时不仅没用，还会掩盖真实问题——你分不清是真卡住，还是早就该报错退出了。
真正慢的环节常是 post-install-cmd 脚本（比如 npm run build），这类应单独拆出 CI 步骤优化，而不是靠拉长总 timeout。如果发现每次都在 3590 秒左右断，八成是中间某个远程服务（如 GitHub API）在限流，得查日志里的具体错误码。
