永久生效的超时配置须写入 Composer 全局或项目级 config.json，仅 process-timeout 和 http-basic-timeout（v2.2+）有效；运行 composer config -g process-timeout 1800 和 composer config -g http-basic-timeout 300 即可全局设置，注意避免环境变量、权限、路径及 PHP 底层超时覆盖。
永久生效的超时配置必须写入 Composer 全局或项目级 config.json，且仅 process-timeout 和 http-basic-timeout（v2.2+）被真正读取；timeout、http.timeout（旧版）等字段在新版中已失效或优先级极低。
怎么写入全局永久配置
全局配置影响当前用户所有项目，适合 CI 镜像预置或本地统一管理：
- 运行
composer config -g process-timeout 1800—— 控制整个install/update流程最大耗时（含下载、解压、脚本执行），推荐值 1200～1800 - 运行
composer config -g http-basic-timeout 300—— 控制单次 HTTPS 请求（DNS + TLS 握手 + 传输）总时长，v2.2+ 唯一有效的 HTTP 层超时项 - 不要用
composer config -g timeout 1800：该字段不被识别，Composer 静默忽略 - 不要加引号：
"process-timeout": "1800"❌，必须是"process-timeout": 1800✅ - 配置后路径可能为
~/.config/composer/config.json（新版）或~/.composer/config.json（旧版），用composer global config --list --verbose看第一行Loaded config file:才准
怎么验证配置是否真实生效
别信 composer config -g process-timeout 的输出——它只显示你上次写入的值，不反映实际加载结果：
- 执行
composer global config --list --verbose，确认Loaded config file:指向的文件里确实有"process-timeout": 1800和"http-basic-timeout": 300 - 临时清空环境变量干扰：
COMPOSER_PROCESS_TIMEOUT= COMPOSER_HTTP_TIMEOUT= composer config -g process-timeout，排除变量覆盖 - 运行
composer install -vvv，观察日志里是否出现类似Process timeout: 1800s或HTTP timeout: 300s的提示（部分版本会打印） - 故意触发超时测试：改一个不存在的镜像源 URL，再运行
composer clear-cache && composer install -vvv，看报错前是否真等够你设的秒数
为什么改了还是不生效
常见静默失效原因不是配置写错，而是被更高优先级机制覆盖或路径错位：
-
COMPOSER_PROCESS_TIMEOUT=0环境变量存在时，它会完全覆盖process-timeout配置，且值为 0 表示禁用超时——CI 中常因基础镜像残留导致 - 用了
sudo composer config -g：写入的是 root 用户的 config.json，但日常命令以普通用户运行，读的是另一个文件 -
COMPOSER_HOME环境变量拼错（如含~或大小写错误），Composer 退回到默认路径，你改的文件根本没被加载 - 项目级
composer.json里也写了config.process-timeout，它优先级高于全局配置；若值更小（如 300），就会覆盖你设的 1800 - 某些 CI 平台（如 GitHub Actions）默认启用
cache: composer，旧缓存里的元数据仍指向老超时逻辑，必须composer clear-cache再跑
最易被忽略的一点：改完 http-basic-timeout 后，PHP 自身的 default_socket_timeout 若小于该值（查法：php -i | grep default_socket_timeout），连接会在 Composer 之前就被 PHP 中断——这个底层限制不会报错，只会让超时表现得“比你设的还短”。
