Composer超时需同时调高process-timeout和http-basic-timeout：前者控命令总耗时（含解压、脚本），后者控单次HTTP请求（如下载大ZIP包），默认60秒易触发cURL 28错误；只改其一无效，且二者独立生效。
Composer 更新频繁超时，不是网络差，而是默认的 process-timeout 和 http-basic-timeout 双重限制太紧，且两者必须同时调高才有效。
为什么只改 process-timeout 还会超时
因为 process-timeout 控制整个命令生命周期（含依赖解析、下载、解压、运行脚本），而 http-basic-timeout 控制单次 HTTP 请求（比如拉一个 50MB 的 dist ZIP 包）。两者独立生效：解析快但包大，process-timeout 没到，http-basic-timeout 先炸了。
常见错误现象：Downloading https://mirrors.aliyun.com/composer/dist/monolog/monolog/2.10.0.0-zip 卡住 60 秒后报 curl: (28) Operation timed out —— 这就是 http-basic-timeout 在起作用。
-
http-basic-timeout默认仅 60 秒，Composer 2.2+ 才支持；旧版本只能靠换镜像或加--timeout硬扛 - 设为
0表示不限时，但不建议：一旦服务器失联或返回空响应，进程会永久挂起 - 推荐值：大项目设
300（5 分钟），CI 环境可设600，避免因临时抖动失败
composer config -g 配置为何经常不生效
全局配置写错位置、权限不对、或被环境变量覆盖，都会导致“明明配了却没用”。最典型的是用 sudo composer config -g，结果把配置写进了 /root/.composer/config.json，而普通用户执行 composer global require 读的是 $HOME/.composer/config.json。
另一个隐形坑是 PHP 禁用了 putenv()（见 php.ini 中 disable_functions），此时 composer config -g 静默失败，不报错也不写入。
- 确认生效：执行
composer clear-cache && composer global require monolog/monolog -vvv 2>&1 | grep "packages.json"，看 URL 是不是镜像地址 - 漏掉
type参数会导致配置静默失败：正确写法是composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，中间的composer是 type，不能省 - CI 环境中必须显式设置
COMPOSER_HOME和COMPOSER_PROCESS_TIMEOUT，否则容器重启后配置丢失
哪些场景必须禁用并行下载
在 WSL2、Docker for Mac、NTFS 挂载卷或低配 CI 节点上，并行下载容易触发系统级文件句柄耗尽或 I/O 阻塞，表现为卡在 Downloading 后无响应，或 Generating autoload files 阶段长时间不动 —— 这其实不是网络问题，而是 PHP 扫描 vendor 目录时被系统限流。
- 禁用方式：
composer config -g use-include-path false，再配合COMPOSER_PROCESS_TIMEOUT=0（部分 Composer 版本更认这个环境变量） - 若项目含私有 GitLab/GitHub 仓库，别把它们加进
repositories镜像配置里：镜像不代理 VCS 源，反而会导致Failed to clone https://xxx: could not connect to server - 离线调试可用：
COMPOSER_DISABLE_NETWORK=1 composer install，跳过所有网络请求，快速验证是否真为网络问题
真正难处理的不是 timeout 值设多少，而是当多个配置项（process-timeout、http-basic-timeout、COMPOSER_PROCESS_TIMEOUT、default_socket_timeout）同时存在时，它们的优先级和生效范围互不透明。实操中建议统一用 composer config -g 写入，避免混用环境变量和命令行参数造成预期外覆盖。
