Composer的--timeout参数必须带等号（如--timeout=1200）才生效，否则静默忽略；它仅临时延长总执行时限，需配合--http-basic-timeout应对HTTP下载超时，推荐永久配置全局process-timeout和http-basic-timeout值。
composer update --timeout= 参数必须带等号才生效
不写等号的 composer update --timeout 1200 会被静默忽略，实际仍走默认 300 秒；正确写法是 composer update --timeout=1200，表示整个命令生命周期最多运行 20 分钟。该参数只对当前命令起作用，适合 CI 流水线中单次救急，比如 GitHub Actions 的 job 步骤里显式加这一行。
线上环境要同时调高 http-basic-timeout
仅加 --timeout 不够——如果卡在 downloading 某个 zip 包，大概率是单次 HTTP 请求超时（默认仅 60 秒），而 --timeout 控制的是总耗时。Composer 2.2+ 才支持 --http-basic-timeout=300，建议和 --timeout 一起用：composer update --timeout=1800 --http-basic-timeout=300。旧版本没这个参数，只能靠换镜像或升级 Composer。
永久设置别依赖命令行，优先改全局 config
线上部署脚本里反复写长参数易出错，也难维护。直接运行这两条命令即可持久化配置：
composer config -g process-timeout 1800composer config -g http-basic-timeout 300
它们会写入 ~/.composer/config.json，所有后续 composer update 自动生效。注意设为 0 表示禁用超时，但线上不推荐——一旦镜像不可达或网络中断，进程会无限挂起，可能拖垮部署流水线。
超时只是表象，真正卡住常因镜像或内存
即使把 timeout 调到 3600 秒，composer update 仍失败，大概率不是时间问题：
- 检查是否用了国内镜像：
composer config -g repo.packagist应返回类似https://mirrors.aliyun.com/composer/，而不是packagist.org - 确认没 fallback 到官方源：
composer config -g repo.packagist false可禁用兜底 - 线上容器内存不足时，
update在解析锁文件阶段就卡死，和 timeout 无关；php -i | grep memory_limit看是否 ≥ 1.5G
最常被忽略的一点：Docker 容器里设置了 docker run --stop-timeout 30，或者外层用 timeout 300 composer update 包裹，这时 Composer 根本来不及响应自己的 timeout 配置，就被系统级信号 kill 了。
