直接原因是Composer的process-timeout默认300秒被击穿，需用--timeout=1200临时覆盖、composer.json配置"process-timeout":1800项目固化或composer config -g process-timeout 1800全局生效；HTTP层超时则调http-basic-timeout；内存不足或镜像未切对也会导致假性超时。
composer install/update 卡住报 ProcessTimedOutException 怎么办
直接原因是 Composer 自己的 process-timeout 阈值被击穿，不是 PHP 的 max_execution_time 在起作用。它控制的是子进程（比如 git clone、unzip、脚本执行）单次运行时长，默认仅 300 秒，在 CI 或大依赖项目里极易触发。
常见错误信息里一定含：[RuntimeException] The process "" exceeded the timeout，加 -vvv 能看到最后卡在哪条命令上。
- 临时救急：用
composer install --timeout=1200（注意必须带等号），优先级最高，但每次都要写 - 项目级固化：在
composer.json的config段加"process-timeout": 1800，提交后团队一致生效 - 全局统一：运行
composer config -g process-timeout 1800，写入~/.composer/config.json，适合 CI 基础镜像预装 - 设为
0表示禁用超时，不推荐——一旦网络或磁盘异常，进程会无限挂起，CI 流水线卡死
下载包时卡在 Downloading https:// 怎么调
这是 HTTP 层超时，和 process-timeout 完全无关。错误常带 cURL error 28 或反复 retry 后失败，由 http-basic-timeout 控制（Composer 2.2+）或旧版的 http.timeout 控制。
它管的是 DNS 解析 + TLS 握手 + 首字节等待 + 整个 body 传输的总时间，默认仅 300 秒，弱网下非常脆弱。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- Composer 2.2+ 推荐：运行
composer config -g http-basic-timeout 300（单位秒） - 老版本或兼容写法：用
composer config -g http.timeout 600 - 临时覆盖：环境变量
COMPOSER_HTTP_TIMEOUT=1200，比配置文件优先级更高 - 务必同步检查 PHP 的
default_socket_timeout（用php -i | grep default_socket_timeout查），若它比你设的http-basic-timeout小，连接会被 PHP 提前掐断
自定义脚本（如 post-install-cmd）超时怎么解
Composer 脚本本身是 PHP 进程，它的执行时长由 PHP 的 max_execution_time 控制，不是 Composer 的任何 config 项。搜 composer.json timeout 想配脚本超时，注定失败。
典型现象是脚本中途静默退出，或报 PHP Fatal error: Maximum execution time of XXX seconds exceeded。
- 最稳方式：调用前加
php -d max_execution_time=900 composer install，适用于所有脚本场景 - CI/CD 中显式写死：GitHub Actions 里用
run: php -d max_execution_time=900 composer install --no-interaction - 脚本内部用
set_time_limit(0)可行，但必须在逻辑开头就调，且不能被disable_functions禁用 - 注意：Docker 容器中若用了
timeout命令包裹整个composer install，那 PHP 层调再久也没用——系统级中断 Composer 根本收不到
为什么光调 timeout 还是失败？几个关键盲区
延长超时只是兜底，不是根治。很多部署失败表面是 timeout，实际是资源瓶颈被掩盖了。
- 内存不足：报
proc_open(): fork failed - Cannot allocate memory时，process-timeout再大也无解，需调高容器memory_limit（建议 ≥ 1.5G） - 镜像没切对：国内用户仍直连
packagist.org，哪怕 timeout 设到 1 小时，下载速度也可能只有几十 KB/s - 并行下载压垮连接：默认开启并发，弱网下易触发重试风暴，可临时关掉：
composer config -g concurrent-http-downloads 1 - autoload 生成卡死：不是网络问题，而是
vendor/下 symlink 或嵌套过深导致递归扫描超时，应改用composer install --no-autoloader+ 后续手动dump-autoload --optimize
