Composer超时需分层处理：process-timeout控制子进程（如git clone），默认300秒；http-basic-timeout控制单次HTTP请求，默认60秒；二者独立生效，须同时调整，并优先排查DNS、镜像配置及网络连通性。
Composer install/update 时卡住或报超时错误
Composer 默认的网络请求超时是 300 秒（5 分钟），但实际中常因源慢、DNS 不稳或代理问题，在远未到 300 秒时就中断，错误通常不直接说“超时”，而是表现为：file_get_contents(): SSL operation failed、Connection timed out 或卡在 Downloading https://packagist.org/packages.json 不动。
真正决定超时行为的是两个配置项：process-timeout（子进程如 git clone 的超时）和 http-basic-timeout（HTTP 请求超时）。它们默认值不同，且作用范围容易混淆：
-
process-timeout控制git clone、hg update等命令执行时限，默认 300 秒；超时会直接终止并报Process Timed Out -
http-basic-timeout控制 Composer 自身 HTTP 客户端（基于 cURL）的单次请求连接+读取总时限，默认 60 秒；超时表现为cURL error 28或空响应 - 两者独立生效——比如你设了
http-basic-timeout=120，但process-timeout=10，那么一个需要 15 秒 git clone 的包仍会失败
查看当前超时配置值
运行以下命令可确认全局或项目级生效的超时设置：
composer config --list | grep -E "(process-timeout|http-basic-timeout)"
注意：--list 显示的是已显式设置的值；若没输出，说明用的是默认值（process-timeout=300，http-basic-timeout=60）。也可单独查：
composer config process-timeout
composer config http-basic-timeout
如果返回 Not found，就是默认值。别依赖 composer diagnose——它不检查超时配置，只验 JSON 格式和网络连通性。
临时调高超时值快速验证是否是超时导致
不是所有卡顿都该调超时，先排除 DNS、代理、源不可达等更常见原因。确认是超时后，用环境变量临时覆盖最安全（不影响配置文件）：
- Linux/macOS：
COMPOSER_PROCESS_TIMEOUT=600 COMPOSER_HTTP_BASIC_TIMEOUT=120 composer install - Windows PowerShell：
$env:COMPOSER_PROCESS_TIMEOUT="600"; $env:COMPOSER_HTTP_BASIC_TIMEOUT="120"; composer install - Windows CMD：
set COMPOSER_PROCESS_TIMEOUT=600 && set COMPOSER_HTTP_BASIC_TIMEOUT=120 && composer install
这两个变量优先级高于 composer.json 和全局 config，且只对当次命令生效。建议从 600/120 开始试，不要一步设成 0（禁用超时），cURL 层面设 0 可能引发无限 hang，尤其在代理异常时。
永久修改但避免污染项目配置
全局改（影响所有项目）：composer config -g process-timeout 600 和 composer config -g http-basic-timeout 120。但要注意：团队协作时，别人没改就可能复现失败，所以更推荐写进项目 composer.json 的 config 段：
"config": {
"process-timeout": 600,
"http-basic-timeout": 120
}
这样每次 composer install 都自动加载，CI/CD 也一致。但别加进 .gitignore——超时配置属于可复现的环境约束，应版本化。
复杂点在于：有些私有仓库用自签名证书或特殊代理，光调超时没用，得配合 secure-http=false 或 http-proxy。超时只是表象，背后往往是网络路径某环断裂，而 Composer 不会告诉你断在哪一层。
