答案：应调 process-timeout，因其控制 git clone、unzip 等子进程执行时限，默认 300 秒，ci 中大项目易触发；http.timeout 仅影响 http 下载阶段，卡在 executing command 时无效。
CI里执行composer install/update报ProcessTimedOutException该调哪个timeout
调 process-timeout，不是 http.timeout。错误信息里明确含 The process "" exceeded the timeout，说明是子进程（如 git clone、unzip、post-install-cmd）超时被杀，和HTTP下载无关。
-
process-timeout控制单个外部命令最大运行时间，默认仅 300 秒，CI 中大项目或低配 runner 很容易触发 -
http.timeout只管拉packages.json或 ZIP 包的 HTTP 连接总耗时，卡在 “Downloading https://” 才轮到它 - CI 流水线中断通常发生在解压或脚本执行阶段，此时
http.timeout已经完成使命，再调它没用
CI中设置process-timeout最可靠的方式是什么
环境变量 COMPOSER_PROCESS_TIMEOUT 优先级最高，且不依赖配置文件写入权限，适合容器化 CI 环境。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- GitHub Actions 中直接写：
COMPOSER_PROCESS_TIMEOUT: 1800（30 分钟），比composer config -g更稳——容器每次启动都重置全局配置 - GitLab CI 中加：
variables: { COMPOSER_PROCESS_TIMEOUT: "1800" } - Docker 内执行时，确认外层没被
timeout命令或docker run --stop-timeout包裹，否则 Composer 根本来不及响应就挂了 - 设为
0表示禁用超时，但不推荐：一旦某条git clone卡死，整个 job 就无限挂起
为什么设置了process-timeout还是失败？常见漏点
多数“设了还超时”不是参数没生效，而是被其他层级的限制截断了。
- PHP 自身的
max_execution_time被disable_functions禁用，导致set_time_limit()报错——CI 镜像常默认禁用它 -
memory_limit不足（尤其composer update解析锁文件时），会先 OOM 再被误判为超时；建议 ≥ 1.5G - CI runner 的系统级超时（如 GitHub Actions 默认 6h，但某些自建 runner 设了 20 分钟硬限制）比 Composer 超时更早触发
- 用了
--no-dev但脚本里又调了phpstan这类 dev-only 工具，实际根本没装上，脚本执行失败被当成超时
自定义脚本（如post-install-cmd）超时怎么办
这类脚本由 PHP 进程直接执行，受 PHP 的 max_execution_time 控制，和 process-timeout 无关。
- 不能在
composer.json的config段加timeout字段——那字段只对 HTTP 生效 - 临时方案：
php -d max_execution_time=0 composer install，强制 PHP 不中断 - 长期方案：在脚本入口处手动调
set_time_limit(0)，但必须放在逻辑最前面，否则可能被后续 require 覆盖 - CI 中更稳妥的是剥离成独立可执行文件（如
scripts/install-hooks.php），并确保它自身 exit code 正确，避免被 Composer 封装吞掉失败信号
composer install -vvv 看最后一条执行的命令是什么，再决定动哪一层。网络、内存、权限、镜像源，都可能伪装成“超时”。
