Composer 卡住非因内置15小时超时，而是网络请求无限重试或进程被杀导致；需组合设置COMPOSER_PROCESS_TIMEOUT、COMPOSER_HTTP_TIMEOUT环境变量及php.ini中default_socket_timeout，并排查镜像源、DNS、OOM等问题。
Composer install/update 卡住 15 小时？不是超时，是默认没设限
Composer 本身没有内置的“15 小时超时”机制——你看到的长时间卡顿，通常是网络请求（比如 git clone、curl 下载包）在后台无限重试，或 PHP 进程被系统 kill 后未报错导致的假性冻结。真正的超时控制得靠两层：PHP 配置和 Composer 自身参数。
怎么让 composer 命令真正「到点就停」
关键不是加一个“超时开关”，而是组合控制底层行为：
-
COMPOSER_PROCESS_TIMEOUT环境变量：控制单个外部进程（如git、svn）最长运行秒数，默认 300（5 分钟）。想缩短卡死风险，设成60或120更实际 -
COMPOSER_HTTP_TIMEOUT环境变量：限制 HTTP 请求（如访问 packagist.org）的等待时间，默认 600（10 分钟）。国内网络不稳定时建议设为30～60 -
--timeout参数只对composer install和update的整体执行有效，但**不包含子进程**（比如 git clone），所以单靠它不够 - PHP 的
max_execution_time对 CLI 模式默认是0（不限制），改它没用；真正要调的是default_socket_timeout（php.ini 中），建议设为30
常见错误现象和对应解法
遇到卡住，先别急着改 timeout，先看日志里真正在等什么：
- 卡在
Cloning xxxxx：说明 git 操作慢或失败 → 设置COMPOSER_PROCESS_TIMEOUT=60+ 换镜像源（如阿里云：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/） - 卡在
Loading composer repositories with package information：HTTP 请求挂起 → 设置COMPOSER_HTTP_TIMEOUT=45+ 检查 DNS 或代理 - 命令突然退出但无错误：可能是系统 OOM killer 杀了进程 → 查
dmesg | tail，不是 timeout 问题，得加内存或减并发（--no-plugins --no-scripts临时降低负载） - 用了
composer update --dry-run还卡：说明依赖解析阶段就卡住 → 尝试composer update --lock跳过解析，或删掉composer.lock再试（慎用）
为什么改了 timeout 还没用？检查这三点
很多情况下你以为改了，其实根本没生效：
- 环境变量没传给子 shell：Windows 用
set COMPOSER_HTTP_TIMEOUT=30 && composer install，Linux/macOS 必须用COMPOSER_HTTP_TIMEOUT=30 composer install（不能写成export后再跑，某些 CI 环境会丢） - 配置写进了全局 config 但被项目级 config 覆盖：运行
composer config --list --global和composer config --list对比，确认生效位置 - 用了 Docker 或 CI 工具（如 GitHub Actions）：环境变量需显式注入，GitHub Actions 中要写进
env:块，不能只写在 run 行里
超时逻辑本身不复杂，难的是定位到底哪一层在卡——网络？DNS？Git？还是 packagist 元数据解析？盯着 log 里最后一行动词，比盲目调数字有用得多。
