Composer自定义脚本超时由PHP的max_execution_time控制，非Composer配置项；需通过php -d max_execution_time=0或脚本内set_time_limit()调整，process-timeout和http-timeout对此无效。
Composer 执行自定义脚本（比如 post-install-cmd 或 pre-deploy）失败，大概率不是脚本写错了，而是 PHP 进程自己先超时被杀——process-timeout 管不到它，http-timeout 更是完全无关。
为什么 composer.json 里配 timeout 没用？
很多人在 composer.json 的 config 段加 "timeout": 600，但这个字段根本不存在于 Composer 官方配置中，会被忽略。Composer 没有 config.timeout 这个选项。
-
http-timeout只影响 HTTP 下载（如拉取packages.json、下载 ZIP 包） -
process-timeout只影响 Composer 自己调用的子进程（如git clone、unzip、php artisan optimize） - 你写的脚本（例如
"post-install-cmd": "php build.php"）由 PHP 解释器直接执行，超时由 PHP 自身控制
真正起作用的是 PHP 的 max_execution_time
Composer 脚本本质是 PHP CLI 进程，它的生命周期受 max_execution_time 限制，默认 300 秒（5 分钟）。一旦脚本运行超过该值，PHP 会抛出 Fatal error: Maximum execution time of XXX seconds exceeded 并退出。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 临时生效：运行时加
-d参数，例如php -d max_execution_time=0 composer install - CI/CD 中推荐显式设置，避免依赖系统默认值：
php -d max_execution_time=900 composer run-script post-build - 检查当前 CLI 模式下的实际值：
php -i | grep max_execution_time - 若该值为
0，表示不限制；若被disable_functions禁用，则无法覆盖
脚本内部主动延长超时更可控
如果你能修改脚本源码（比如自定义类或独立 PHP 文件），在逻辑开头调用 set_time_limit() 是最精准的方式。
- 必须在脚本执行早期调用，例如在
MyBuildScript::run()第一行 -
set_time_limit(1200)表示最多再运行 20 分钟（从调用点起算） -
set_time_limit(0)表示取消限制，但部分共享主机或安全策略可能禁止 - 该函数对 CLI SAPI 有效，对嵌入式 PHP（如某些容器环境）可能无效
别忘了 CI/CD 和系统级兜底限制
即使 PHP 层调大了，外部环境仍可能中断进程：
- GitHub Actions 默认 job 超时 6 小时，但单个 step 若没输出可能被判定为挂起（建议脚本内定期
echo或使用timeout命令包装） - Docker 容器若设了
--stop-timeout或healthcheck，也可能误杀长任务 - 某些 Linux 发行版的 systemd service 有
RuntimeMaxSec限制，需单独配置 - 手动测试时，别只看 Composer 日志——把报错里的完整命令复制出来，单独执行，确认是不是真慢还是假卡（比如 WSL2 symlink 扫描、杀毒软件拦截）
最易被忽略的一点：process-timeout 设再大，对纯 PHP 死循环也无济于事；而 max_execution_time 再大，也救不了被防火墙静默丢包的 git clone。问题在哪一层，就得在哪一层调。
