卡在Downloading https://时应设COMPOSER_HTTP_TIMEOUT环境变量，它优先级最高且覆盖http.timeout；同时需确保PHP的default_socket_timeout不低于该值，否则连接会在Composer层前被掐断。
卡在 Downloading https:// 时该设哪个环境变量
直接设 COMPOSER_HTTP_TIMEOUT，它会覆盖 http.timeout 配置项，且优先级最高。Composer 2.x 在 HTTP 请求阶段（拉 packages.json、下载 ZIP 包）只认这个值，process-timeout 完全不生效。
常见错误是把超时调高了却仍失败——因为 PHP 自身的 default_socket_timeout 更低，连接会在 Composer 层之前被掐断。运行 php -i | grep default_socket_timeout 查出当前值（常为 60），若低于你设的 COMPOSER_HTTP_TIMEOUT，必须同步调高，例如：
php -d default_socket_timeout=1200 -d max_execution_time=0 composer install
-
COMPOSER_HTTP_TIMEOUT=1200：适用于弱网或首字节延迟高的镜像源（如某些私有仓库） - 值设太高（如 3600）反而掩盖真实问题，调试建议从 600 起步
- URL 末尾必须带
/，否则拼接路径出错，镜像源配置静默失效
The process timed out 错误该用哪个环境变量兜底
这是子进程执行超时，比如 git clone、unzip 或 post-install-cmd 脚本卡住，错误里一定含 [RuntimeException] The process "" exceeded the timeout。此时唯一有效的环境变量是 COMPOSER_PROCESS_TIMEOUT。
它控制每个外部命令的最大执行时间，和 HTTP 完全无关。默认 300 秒太短，尤其在 CI 中跑大项目或含 symlink 的 vendor 目录时极易触发。
- 设为
0表示不限时，但不推荐——万一远程 Git 仓库 DNS 解析失败，会无限挂起 - CI 环境建议设为
1800（30 分钟），比命令行参数--timeout更可靠，能覆盖插件启动的子进程 - 注意：某些旧版 Composer 对
COMPOSER_PROCESS_TIMEOUT敏感度更高，而对--timeout忽略，务必优先用环境变量
为什么改了 composer.json 还没用
因为 config.timeout 是 Composer v1 废弃项，v2 完全不读取；而 process-timeout 和 http.timeout 都不能写进 composer.json 的顶层 config 段——它们只支持全局或项目级 config 命令写入，或环境变量覆盖。
典型误操作："config": {"timeout": 600} 这种写法无效；正确做法是运行：
composer config http.timeout 600
这条命令会把配置写入当前项目的 composer.json 的 config 段，且格式必须是：
"config": {
"http.timeout": 600,
"process-timeout": 1800
}
- 项目级配置可提交、可复现，比全局配置更可控
- 环境变量优先级 > 项目级配置 > 全局配置，CI 中推荐三者组合使用
- 换源后必须执行
composer clear-cache，否则旧缓存仍走失败地址
Docker 或 CI 中最易漏的底层限制
容器内常因 DNS 配置不当导致 Resolving dependencies 卡死，这不是超时问题，而是根本没发出去请求。此时设任何 COMPOSER_* 变量都无效。
必须检查容器启动时是否指定可信 DNS，例如：
docker run --dns 8.8.8.8 --dns 114.114.114.114 your-image composer install
另外，WSL2 或某些内网环境存在 symlink 解析慢、APCu CLI 未启用等问题，会导致 Generating autoload files 后无响应——这和网络超时无关，但现象相似，容易误判。
-
COMPOSER_PROCESS_TIMEOUT设再高也救不了 autoload 阶段的 I/O 阻塞 - 若
-vvv输出停在Generating autoload files，应查 PHP 配置而非网络参数 - CI 中建议加
--prefer-dist强制用 ZIP 包，避免git clone触发额外超时分支
