Composer自定义脚本（如post-install-cmd）超时由PHP的max_execution_time控制，非Composer配置项；需用php -d max_execution_time=0 composer install临时调整，或在脚本中调用set_time_limit()，同时检查memory_limit、交互阻塞及CI平台超时。
Composer执行自定义脚本（如post-install-cmd）超时，不是改composer.json里的timeout配置能解决的——那个只管HTTP下载，不管PHP脚本运行时间。
为什么php -d max_execution_time才是关键
Composer调用的脚本（比如php artisan config:cache）本质是另一个PHP进程，受PHP自身的max_execution_time限制，而非Composer控制。默认300秒（5分钟）一到，直接抛Fatal error: Maximum execution time of 300 seconds exceeded或静默中断。
- 在
composer.json的config块里写"timeout": 600完全无效 -
COMPOSER_PROCESS_TIMEOUT环境变量或--process-timeout参数只影响Composer主进程拉包、解压等子命令，不覆盖你scripts里调用的PHP命令 - CI/CD中常见静默失败，尤其在Docker容器里——因为
max_execution_time常被设为30秒或更低
三种可靠生效的调整方式
按优先级排序，推荐组合使用：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 临时提权最稳：
php -d max_execution_time=0 composer install（0表示不限制），适合CI流水线或本地调试 - 脚本内主动延长：在你的脚本入口第一行加
set_time_limit(600)，但注意它只对当前PHP进程有效，且不能在safe_mode下用 - 全局放宽CLI配置：编辑
php.ini（确认是CLI用的那个，运行php --ini查路径），把max_execution_time = 0，避免每次命令都加参数
容易被忽略的干扰项
即使max_execution_time调高了，仍可能卡住，原因常不在PHP本身：
-
memory_limit不足：大型Laravel项目跑artisan config:cache时内存爆掉，错误表现为超时假象；建议设为-1或至少1.5G - 脚本内部阻塞：比如
php artisan key:generate依赖/dev/urandom，某些容器里没挂载会导致几秒到几十秒随机等待 - 交互式命令未关闭：脚本里调用
php artisan没加--no-interaction，遇到提示就卡死，看起来像超时 - CI平台自身超时：GitHub Actions的
timeout-minutes或GitLab CI的interruptible设置会提前kill整个job，Composer根本来不及报错
真正要调的从来不是“Composer超时”，而是你脚本运行的那个PHP进程的生存时间——盯住php -i | grep max_execution_time输出，比翻composer.json有用十倍。
