Composer timeout设置如何写入全局配置-composer-PHP中文网

必须用composer config --global设置全局timeout，否则写入项目级配置无效；process-timeout、http.timeout、http-basic-timeout须为整数且键名严格匹配，验证需结合-vvv日志观察实际行为。

composer timeout设置如何写入全局配置

composer config -g 写入全局 timeout 配置的正确姿势

必须用 composer config --global，否则写进的是当前项目的 composer.json，对其他项目完全无效。timeout 类配置（如 process-timeout、http.timeout、http-basic-timeout）只在全局或项目级 config 段生效，但只有全局设置能跨项目起作用。

process-timeout 控制命令执行超时（如 git clone、php 脚本），单位秒，值必须是整数：composer config --global process-timeout 1200
http.timeout 控制 HTTP 下载超时（如获取 packagist.org 的 packages.json），Composer 2.0+ 支持，同样要整数：composer config --global http.timeout 600
http-basic-timeout 仅 Composer 2.2+ 支持，专用于 Basic Auth 场景（如私有仓库带账号密码），不能和 http.timeout 混用：composer config --global http-basic-timeout 900
别写错键名：不是 timeout、process_timeout 或 http-timeout，连字符和大小写必须严格匹配官方命名

为什么写了却没生效？常见静默失败原因

Composer 不报错，但配置被忽略——这是最典型的“假写入”。核心问题就两个：路径不对、格式不对。

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

先确认真实全局配置路径：composer config --global --list --verbose，首行显示的 Global configuration file 才是唯一有效位置；若显示 /home/user/.config/composer/config.json，那 ~/.composer/config.json 里的内容全作废
值必须是整数，不能加引号："process-timeout": "1200" ❌（字符串会被忽略），"process-timeout": 1200 ✅
Windows 上用 Git Bash 时，%APPDATA% 不自动展开，composer config --global 可能写到空目录；换 PowerShell 或 CMD 重试
如果设了 http.timeout 600 但下载仍卡在 60 秒，检查 PHP 底层：php -i | grep default_socket_timeout，若输出 60，说明 PHP 自己掐断了连接，Composer 设置无效

怎么验证 timeout 配置真正在用？

看输出比看配置文件更可靠。运行带详细日志的命令，观察实际触发行为。

执行 composer update -vvv，留意开头几行是否出现 Running update with --timeout=1200（仅当显式传 --timeout 参数时才打这个）
更关键的是看下载阶段：若之前卡在 Downloading https://mirrors.aliyun.com/composer/packs/xxx.json，调高 http.timeout 后仍 60 秒中断，说明该参数没读到，大概率是 Composer 版本太低（http-basic-timeout 需 2.2+）
若卡在 Executing command (CWD: /path): git clone，而你只改了 http.timeout，那完全不相关——得查 process-timeout
最终验证：删掉刚设的值，再 composer config --global --list | grep timeout，无输出即已清空；此时 composer update 应恢复默认 300 秒超时行为

CI/CD 或 Docker 环境里 timeout 配置容易被覆盖

全局配置只是 Composer 层的一环，上层系统限制会让它彻底失效。

Docker 运行时若加了 --stop-timeout 30，容器可能在 Composer 超时前就被强制 kill，process-timeout 完全没机会触发
GitLab CI 的 timeout: 或 GitHub Actions 的 timeout-minutes: 是硬性上限，Composer 自己的 timeout 再大也突破不了
某些 runner（如 self-hosted）自带 shell 级 timeout，比如 timeout 300 composer update，这时 Composer 根本等不到自己设的 1200 秒
建议做法：在 CI 脚本里统一用 timeout 命令包裹，并把 Composer 的 process-timeout 设为略小于它（如 shell timeout 1800s，则 Composer 设 1700）

真正难的不是写进配置，而是确认它被哪个进程、在哪个上下文、经由哪一层网络栈实际应用——尤其当错误提示只显示 “Connection timed out” 却不告诉你到底是 PHP socket、curl、git 还是 shell 在掐断连接。