Composer如何设置超时时间_Composer timeout超时设置教程【详解】-composer-PHP中文网

process-timeout 控制子进程执行时长，如 git clone、解压、脚本运行等，与网络请求无关；默认300秒，设为0禁用；可通过命令行、项目级config或全局config修改。

composer如何设置超时时间_composer timeout超时设置教程【详解】

process-timeout 控制的是什么？别和网络超时搞混

你执行 composer install 卡在 “Installing dependencies” 或报 [RuntimeException] The process timed out.，大概率是 process-timeout 在起作用——它只管子进程（比如 git clone、unzip、php artisan optimize）跑了多久，和下载慢、连不上包源完全无关。

process-timeout 默认 300 秒（5 分钟），单位是秒，设为 0 表示禁用（不推荐，真卡死就没人喊你了）
它不影响 HTTP 请求，所以调高它对 Could not fetch https://repo.packagist.org/packages.json 这类错误无效
常见触发点：大体积私有包解压、老旧插件（如 hirak/prestissimo）、WSL2 下 symlink 扫描、或某个 post-install-cmd 脚本本身慢
加 -v 参数运行可定位具体卡在哪一步：composer install -v，看最后输出的命令是不是长时间没反应

三种改法，适用场景完全不同

别一股脑全设全局，不同场景该用哪种方式得看清楚：

临时一试：命令行加参数，比如 composer update --process-timeout=1800（30 分钟），适合 CI 调试或救急
项目级生效：进项目目录后运行 composer config process-timeout 1800，会写入当前 composer.json 的 "config" 段，不影响其他项目
全局生效：运行 composer config -g process-timeout 1800，写入 ~/.composer/config.json，所有项目都受控——但注意，某些旧版 Composer（

⚠️ 注意：composer config --global process-timeout 在部分版本中已废弃，不如直接用环境变量保险。

Discussion Composer

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

下载

HTTP 层超时怎么调？用 http-timeout，不是 process-timeout

如果你看到的是 Failed to download vendor/package: curl error 28 while downloading https://... 或卡在 Downloading https://，这才是真正的网络请求超时，该动 http-timeout。

默认也是 300 秒，可通过 composer config --global http-timeout 600 设为 10 分钟
它控制的是 Composer 内部 cURL / stream_context 的读取上限，和 PHP 的 default_socket_timeout 有关联，但不用手动改 php.ini
环境变量 COMPOSER_PROCESS_TIMEOUT 只影响子进程，对 HTTP 无效；http-timeout 也不能用环境变量设置
国内用户更建议先换镜像源：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，比硬调超时更治本

容易被忽略的坑：镜像不代理 Git，私有仓库还得另想办法

很多人以为换了阿里云镜像就万事大吉，结果遇到 Failed to clone git@xxx 或 could not connect to server，才发现镜像只加速 Packagist 公共包，对 git@、https://github.com/、https://gitlab.internal/ 这类 VCS 源完全不生效。

私有 Git 仓库超时，要调 Git 自身配置，比如 git config --global core.sshCommand "ssh -o ConnectTimeout=30"
企业内网 Git 服务（如 Gitee 企业版）可能自带连接限制，Composer 改了也没用
若项目里硬编码了 "repositories" 字段，它的优先级高于全局镜像配置，记得检查并清理冗余项
CI 环境中，--no-interaction 必须配合显式超时设置，否则容器重启后配置丢失，又回到默认 300 秒

真正麻烦的从来不是超时数字设多大，而是分不清哪一层在超时、哪一层该由谁来调。