Composer 的 --timeout 参数必须带等号（如 --timeout=600），否则无效；推荐长期使用 COMPOSER_PROCESS_TIMEOUT 环境变量，它优先级更高且更稳定；该参数仅控制 Composer 主进程，不包括 post-install-cmd 脚本，后者受 PHP 的 max_execution_time 限制。
CI/CD 里用 --timeout= 参数必须带等号
在 GitHub Actions、GitLab CI 或 Jenkins 中执行 composer install 时，直接写 composer install --timeout 600 是无效的——Composer 会静默忽略这个参数。它只认 --timeout=600 这种带等号的写法。
- 正确示例：
composer install --no-interaction --timeout=900 - 错误写法：
composer install --timeout 900（无等号，不生效） - 该参数仅对当前命令有效，适合单步调试或临时放宽；长期使用建议统一走环境变量
推荐用 COMPOSER_PROCESS_TIMEOUT 环境变量
环境变量优先级高于命令行参数，且更稳定，尤其适合容器化或 CI 环境。设为 0 表示禁用超时，但别长期用——万一镜像源挂了，进程会无限卡住。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- GitHub Actions 示例：
env: COMPOSER_PROCESS_TIMEOUT: 900
- Docker 中需确认未被
docker run --stop-timeout覆盖，否则 Composer 还没自己超时就被系统 kill - 若 PHP 的
max_execution_time被disable_functions禁用，set_time_limit()会报错，此时只能靠环境变量或 CLI 参数
脚本阶段超时要单独处理
--timeout 和 COMPOSER_PROCESS_TIMEOUT 控制的是 Composer 主进程生命周期，不包括你自定义的 post-install-cmd 脚本。这些脚本由 PHP 直接执行，超时由 PHP 的 max_execution_time 决定。
- 最稳妥方式：
php -d max_execution_time=0 composer install - 若脚本已封装成类，可在入口第一行调
set_time_limit(1200)，但必须早于任何耗时操作 - 注意：Laravel 的
php artisan命令本身也有超时逻辑，加--no-interaction可避免因等待输入导致假性卡死
别只调 timeout，先确认是不是真超时
很多“超时”其实是内存不足或 I/O 阻塞。比如 Generating autoload files 卡住，常因 vendor 下 symlink 过多或 NTFS 挂载卷性能差；Downloading 卡住，大概率是没切国内镜像源，而不是时间不够。
- 先跑
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 检查
memory_limit是否 ≥ 1.5G，尤其composer update解析锁文件阶段易 OOM - 私有 VCS 包（如
"type": "vcs"）不受镜像加速，git clone 卡顿需单独排查 SSH 或代理
--timeout=300 根本没用。 
