processtimedoutexception是因composer默认process-timeout（300秒）过短所致，需按临时、项目、全局三级配置调整；注意其与http timeout无关，且盲目设为0可能掩盖内存不足、脚本死循环等真实问题。
composer install 或 update 卡住后报 ProcessTimedOutException
这是最典型的超时表现：命令跑着跑着突然中断，抛出类似 proc_open(): fork failed - Cannot allocate memory 或更常见的 Composer\Downloader\TransportException 带 process timeout 字样。根本原因不是网络慢，而是 Composer 默认的 process-timeout 太保守（默认 300 秒），尤其在装扩展多、依赖深、或本地 PHP 配置低的机器上极易触发。
怎么改 process-timeout：全局 vs 项目 vs 临时
三种改法效果不同，别混用：
- 临时生效（推荐调试用）：
composer install --process-timeout=0或composer update --process-timeout=1800（单位秒，0表示不限制） - 项目级配置（写进
composer.json）："config": { "process-timeout": 1800 }，只影响当前项目，提交后别人也能用 - 全局配置（慎用）：
composer config -g process-timeout 1800，所有项目都受它影响，升级 Composer 后可能重置
注意：--process-timeout 参数优先级高于 composer.json 里的 config，而后者又高于全局配置。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
process-timeout 和 timeout 不是一回事
很多人搜到 timeout 就直接改，结果没用——那是 HTTP 请求超时（控制下载包时的网络等待），和 process-timeout 完全无关。后者管的是「执行某个命令」的时间，比如 git clone、unzip、php -r "..." 这类子进程。常见误区：
- 以为调大
timeout能解决ProcessTimedOutException→ 实际无效 - 在
composer.json里写"timeout": 3600→ Composer 忽略该字段，不报错但也不起作用 - 用
COMPOSER_PROCESS_TIMEOUT环境变量覆盖 → 可行，但优先级低于命令行参数，且容易被遗忘
超时调太大反而会掩盖真问题
process-timeout=0 虽然能“跑通”，但可能把内存耗尽、死循环、权限错误等底层问题藏起来。比如：
- 某包的
post-install-cmd脚本卡死，无限重试 → 超时设太长只会让机器假死更久 - PHP
memory_limit不足，导致解压失败后反复重试 → 光调超时没用，得同步调高memory_limit - Git 仓库不可达，Composer 会不断重试 SSH/HTTPS → 应先确认网络或换镜像源，而不是无脑加超时
真正稳的做法是：先定位哪个具体步骤超时（看最后几行日志里的命令），再针对性优化，而不是一上来就设成 0。
