“版本检查超时”本质是网络层问题：DNS解析失败导致卡在Resolving dependencies，需检查DNS、hosts及镜像源格式；HTTP超时才影响Downloading阶段，由http.timeout等参数控制；process-timeout用于解决执行命令或生成autoload卡死。
“版本检查超时”不是 Composer 在校验你本地版本，而是它在连远程源查包元数据时卡死——本质是网络层问题，不是版本管理逻辑出错。
卡在 Resolving dependencies 是 DNS 或域名访问失败
这一步只做域名解析（比如查 mirrors.aliyun.com 的 IP），不发 HTTP 请求，也不读代理、不走 http.timeout。调任何超时参数都无效。
- 运行
dig mirrors.aliyun.com @114.114.114.114，看是否返回 IPv4 地址；无响应说明本地 DNS 被污染或不可用 - 临时换 DNS：Linux/macOS 编辑
/etc/resolv.conf加nameserver 8.8.8.8；Windows 在网络适配器里手动设 - 检查
/etc/hosts（或C:\Windows\System32\drivers\etc\hosts）是否把mirrors.aliyun.com指向了127.0.0.1或错误 IP - 用手机热点试一次——很多企业网会屏蔽
packagist.org域名，但热点通常直连通畅
卡在 Downloading https://... 是 HTTP 请求超时
只有到这步才真正发起 HTTP 请求，http.timeout 和 http.proxy 才起作用。注意：http-basic-timeout 是 Composer 2.2+ 新增参数，旧版不识别。
- 全局延长单次请求等待：运行
composer config -g http.timeout 600（单位秒） - 项目级更稳妥（尤其 CI）：在
composer.json的"config"段加"http.timeout": 600 - 代理必须用
http.proxy配置项，格式为http://user:pass@127.0.0.1:8080；密码含特殊字符需 URL 编码 - 镜像源配置漏一个斜杠也会失效：
https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌
卡在 Executing command 或 Generating autoload files 不是网络问题
这类“超时”实际是子进程卡死或文件系统阻塞，process-timeout 控制的是整个命令生命周期，包括解压、执行脚本、生成 autoload 等。
- 设高总时限：运行
composer config -g process-timeout 1200（20 分钟） - CI 中建议用环境变量：
COMPOSER_PROCESS_TIMEOUT=1200，比命令行参数覆盖更全 - 若停在
Generating autoload files后无响应，检查 WSL2/NTFS 挂载卷 symlink 解析慢、APCu 是否启用 CLI 模式、PHPmax_execution_time是否过低 - 禁用并行下载可减压：
composer config -g use-include-path false，再配合COMPOSER_PROCESS_TIMEOUT=0（慎用）
真正容易被忽略的是：镜像源配置成功后，必须执行 composer clear-cache，否则旧缓存仍会复用失败地址；而验证是否生效最可靠的方式，是直接 curl -I https://mirrors.aliyun.com/composer/packages.json，别只信 Composer 日志输出。
