composer不支持主动限制运行时间，仅能通过--timeout=600等参数延长默认300秒的process-timeout阈值以避免卡死；该参数临时生效，需带等号，且无法解决网络或资源瓶颈问题。

Composer 命令本身不支持“限制运行时间”（即主动中断超时），它只提供“延长或禁用超时”的能力；所谓“限制”，实际是调整它的默认 300 秒熔断阈值，防止卡死。

composer install/update 的 --timeout 参数怎么用

这是最常用、最直接的控制方式，用于覆盖默认的 process-timeout 值：

• --timeout=600 表示整个命令生命周期最多运行 10 分钟，超时后抛出 ProcessTimedOutException
• 该参数仅对当前命令生效，不影响其他操作，适合 CI/CD 调试或临时救急
• 注意：Composer 2.2+ 才支持 --http-basic-timeout 单独调 HTTP 层超时；若只加 --timeout 但网络慢，仍可能在下载 zip 包时失败
• 错误写法：composer install --timeout 600（少等号）会静默忽略，必须带 =

为什么 set_time_limit() 对 composer install 无效

因为 composer install 是主进程，它通过 proc_open() 启动子进程下载包、解压、执行脚本——set_time_limit() 只作用于当前 PHP 进程，管不了子进程。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

• 你在 post-install-cmd 脚本里调 set_time_limit(0) 是有效的，但仅限该脚本自身
• 你在自定义 PHP 类中调 set_time_limit()，必须确保它在脚本执行早期就触发，否则可能被后续逻辑覆盖
• PHP CLI 模式下若 max_execution_time 被 disable_functions 禁用，则 set_time_limit() 直接报错

COMPOSER_PROCESS_TIMEOUT 环境变量是否可靠

可靠，且优先级高于配置文件，但有隐含行为：

• 设为 0 表示禁用超时，但不推荐长期使用——一旦网络卡死或镜像不可用，命令会无限挂起
• 在 Docker 容器中设置该变量，需确认未被 docker run --stop-timeout 或外层 timeout 命令包裹，否则 Composer 还没反应就被系统 kill
• GitHub Actions 中建议显式写成：COMPOSER_PROCESS_TIMEOUT: 900，避免因 runner 默认 PHP 配置导致意外中断

真正卡住时，别只盯着 timeout

很多“超时”本质不是时间问题，而是资源或配置阻塞：

• 内存不足时，composer update 在解析锁文件阶段会 OOM，表现和超时几乎一样；检查 memory_limit 是否 ≥ 1.5G
• 用了 git 仓库（如 "type": "vcs"），每次 git clone 都计入总超时，不是单次；可先 git clone 测试是否卡在 SSH 或代理
• 国内用户不切镜像源，--timeout=3600 也救不了连不上 packagist.org 的情况；优先执行：composer config -g repo.packagist false + 切阿里云镜像