应通过composer update -vvv | grep timeout查看实际生效值，而非config --list；process-timeout控制git clone等子进程，http.timeout控制HTTP下载，二者独立且环境变量优先级最高。
composer config --list 显示的是默认值，不是运行时生效值
执行 composer config --list 看到的 process-timeout 和 http.timeout 是配置文件里的静态值，不反映当前实际生效的超时逻辑。Composer 在运行时会按优先级合并多个来源（命令行参数、环境变量、配置项、内置默认），最终值未必等于 config 里存的那一个。
用 -vvv 参数触发 debug 输出，找 timeout 相关日志行
真正生效的 timeout 值会在详细日志中明确打印。运行任意网络操作命令（如 composer update）加 -vvv，然后搜索日志里的 timeout：
composer update -vvv 2>&1 | grep -i timeout
你会看到类似这样的行：
Reading ./composer.json<br>Running 2.7.6 (2024-05-22 14:30:12) with PHP 8.2.12 on Linux / 6.5.0-35-generic<br>Downloading https://packagist.org/packages.json using proxy http://127.0.0.1:8080<br>Setting timeout to 300s for https://packagist.org/packages.json
注意最后一行 —— 这个 300s 就是 Composer 当前为该请求实际设置的 HTTP 超时值，它已综合了 http.timeout 配置、COMPOSER_HTTP_TIMEOUT 环境变量和命令行 --timeout 参数。
process-timeout 和 http.timeout 的作用范围完全不同
这两个 timeout 容易混淆，但它们控制的是两类完全不同的操作：
-
process-timeout：只影响本地子进程（比如git clone、svn export、php install.php），单位是秒，默认 300 -
http.timeout：只影响 HTTP(S) 请求（如下载packages.json、.zip包），单位是秒，默认 60
它们互不影响，也不能互相覆盖。比如你设了 http.timeout=10，但某个 git clone 卡住 200 秒，process-timeout 才会起作用，http.timeout 根本不参与。
环境变量会覆盖 config 设置，且优先级最高
如果设置了 COMPOSER_PROCESS_TIMEOUT 或 COMPOSER_HTTP_TIMEOUT，它们会直接覆盖 composer.json 或全局 config 中的同名配置，无需重新 config 写入。验证方式很简单：
- 运行
echo $COMPOSER_HTTP_TIMEOUT看是否非空 - 临时改一个值测试：
COMPOSER_HTTP_TIMEOUT=15 composer diagnose -vvv 2>&1 | grep timeout - 注意：Windows 上要用
set COMPOSER_HTTP_TIMEOUT=15（CMD）或$env:COMPOSER_HTTP_TIMEOUT=15（PowerShell）
很多 CI 环境（如 GitHub Actions）默认设了 COMPOSER_PROCESS_TIMEOUT=0 来禁用超时，这个细节常被忽略，导致本地能过 CI 报错。
