全局超时配置仅作用于~/.composer/config.json，执行composer global require时完全忽略项目级composer.json和composer.lock；必须同时设置process-timeout和http-basic-timeout，并验证镜像与代理对HTTPS生效。
全局超时配置只写~/.composer/config.json，不读项目文件
执行 composer global require 时，Composer 完全忽略当前目录的 composer.json 和 composer.lock，只加载用户级配置文件（通常是 ~/.composer/config.json）和环境变量。这意味着你在项目里配的 "process-timeout": 1800 对全局命令完全无效。
常见失效场景包括：
- 用
sudo composer config -g，结果写进了/root/.composer/config.json，但普通用户运行composer global require读的是$HOME/.composer/config.json - PHP 禁用了
putenv()（见php.ini的disable_functions），导致composer config -g静默失败，配置根本没写进去 - 没清缓存，旧的
packages.json还在本地，命令压根不发网络请求，自然看不出镜像或超时是否生效
process-timeout 和 http-basic-timeout 必须一起设
这两个参数作用域不同，只调一个大概率仍会卡住：
-
process-timeout控制整个命令生命周期（依赖解析、解压、脚本执行等），默认 300 秒。建议设为1200或1800：composer config -g process-timeout 1800 -
http-basic-timeout（Composer 2.2+ 支持）专管单次 HTTPS 请求的总耗时（DNS + TLS 握手 + 首字节 + body 传输），默认仅 60 秒。大包或弱网下极易触发cURL error 28。推荐值300：composer config -g http-basic-timeout 300 - 别用
http.timeout——它在新版中已被http-basic-timeout取代，且旧版默认值太低，容易误判
环境变量优先级最高，但0值有风险
COMPOSER_PROCESS_TIMEOUT 和 COMPOSER_HTTP_TIMEOUT 的优先级高于所有配置文件，包括 composer.json 和 ~/.composer/config.json。例如：
-
COMPOSER_PROCESS_TIMEOUT=0 composer global require laravel/installer会彻底禁用进程超时 - 但
0值不推荐：某些网络环境 TLS 握手失败后会无限重试，进程挂死，Ctrl+C都无法中断 - Docker 容器中设置该变量时，需确认外层没被
timeout 600 composer install包裹，否则系统级 timeout 会先掐断
验证配置是否真生效，不能只看 config -g 输出
执行 composer config -g process-timeout 输出数字，不代表它正在起作用。必须实测请求路径：
- 先清缓存：
composer clear-cache - 再带调试日志运行：
composer global require monolog/monolog -vvv 2>&1 | grep "Downloading\|packages.json" - 看到
Downloading https://mirrors.aliyun.com/composer/packages.json才说明镜像和超时配置都已走通；若仍是https://packagist.org/packages.json，说明全局配置根本没加载成功 - 注意检查
https-proxy是否也同步配置——只配http-proxy会导致 HTTPS 请求静默直连，超时表现一模一样
max_execution_time、也不受 default_socket_timeout 直接控制。真正起效的只有三样东西：环境变量、~/.composer/config.json 里的 process-timeout 和 http-basic-timeout，以及代理是否对 HTTPS 流量生效。 
