Composer脚本超时由process-timeout控制，非PHP的max_execution_time；默认300秒，超时抛出ProcessTimedOutException；--timeout=600需带等号，临时生效，长期建议用composer config process-timeout 1200写入配置。
Composer脚本超时是process-timeout在起作用
Composer自身不依赖PHP的max_execution_time，它用独立的process-timeout控制整个命令生命周期（含子进程），默认300秒。你看到ProcessTimedOutException，说明这个阈值被突破了——不是脚本本身慢，而是Composer启动的php、git、zip等子进程总耗时超限。
-
--timeout=600必须带等号，写成--timeout 600会被静默忽略 - 该参数只影响当前命令，适合CI调试；长期项目建议用
composer config process-timeout 1200写入composer.json - 设为
0表示禁用超时，但风险高：网络卡死时会无限挂起，Docker里还可能被--stop-timeout二次kill
post-install-cmd卡住？先确认是不是脚本真慢
很多“超时”其实卡在post-install-cmd或post-update-cmd里，比如php artisan key:generate因权限/配置问题阻塞，或npm install没加--no-interaction等待输入。这类问题--timeout治标不治本。
- 手动运行脚本验证：
php artisan key:generate --no-interaction，看是否报错或卡住 - 临时跳过脚本测试：
composer install --no-scripts，如果秒完成，问题就出在scripts里 - 脚本里别用
cd切目录——Composer执行时工作目录就是项目根，硬切反而路径错乱 - 某些IDE或部署工具默认加
--no-scripts，检查CI配置里有没有漏掉--scripts
set_time_limit()对脚本有效，但有前提
你在post-install-cmd里调set_time_limit(0)是有效的，但它只延长当前PHP子进程的时限，不影响Composer主进程或其他子进程（如git clone）。
- 必须在脚本开头尽早调用，否则可能被后续逻辑覆盖
- CLI模式下若
set_time_limit被disable_functions禁用，会直接报错，需检查php -i | grep disable_functions - 别在
composer.json的scripts里写php -r "set_time_limit(0); ..."——-r执行完就退出，起不到延长作用 - 更稳妥的做法是把耗时逻辑封装成独立PHP文件，文件头加
#!/usr/bin/env php和set_time_limit(0)，再在scripts里调用它
比调timeout更关键的是别让它卡住
延长超时只是兜底，真正要解决的是“为什么卡”。国内用户不切镜像源，--timeout=3600也救不了连不上packagist.org；内存不足时，composer update在解析锁文件阶段OOM，表现和超时一模一样。
- 优先切阿里云镜像：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 禁用官方源fallback：
composer config -g repo.packagist false，避免兜底请求拖慢整体 - 检查
memory_limit是否≥1.5G，尤其update时解析复杂依赖树 - Git类包卡住？先手动
git clone测试SSH或代理是否通，别让Composer替你背锅
