Composer超时需分层排查：Resolving dependencies卡住是DNS问题；Downloading卡住调http-basic-timeout；Executing command卡住调process-timeout；Generating autoload files卡住查文件系统或PHP配置。
Composer长时间等待后报超时，不是简单加个--timeout就能解决的问题——它大概率卡在某一层，而你调的参数根本不管那层。
看最后一行输出，才能知道卡在哪
运行composer install -vvv或composer update -vvv，紧盯终端最后几行：
- 停在
Resolving dependencies：DNS 解析失败或无法访问packagist.org，跟 timeout 无关；试试dig packagist.org或换 DNS（如114.114.114.114） - 停在
Downloading https://...：HTTP 层卡住，要调http-basic-timeout（Composer 2.2+）或http.timeout（v1 兼容写法） - 停在
Executing command (CWD: ...)：比如git clone或unzip卡死，这时只有process-timeout或环境变量COMPOSER_PROCESS_TIMEOUT起作用 - 停在
Generating autoload files后无响应：不是网络问题，是文件系统慢（如 WSL2 symlink）、PHP 配置（APCu 未启用 CLI 模式）或 vendor 目录结构太深
两个 timeout 参数必须分清用途
process-timeout 和 http-basic-timeout 完全不重叠，混着调等于乱按开关：
-
process-timeout：控制整个命令生命周期（含解压、执行 post-install-cmd、生成 autoloader），默认 300 秒；大项目建议设为1200 -
http-basic-timeout：控制单次 HTTP 请求（TLS 握手 + 首字节等待 + body 传输），默认仅 60 秒；下载大包或镜像首字节延迟高时，设为300～600更实际 -
http.timeout是 v1 遗留字段，v2 中已不读取；设了也白设
CI/CD 环境下光调 timeout 是徒劳的
流水线里超时高频，靠拉长 timeout 只是硬扛，真正要组合出手：
- 必须配国内镜像：
composer config -g repos.packagist.org.url https://mirrors.aliyun.com/composer/ - 禁用 packagist.org 回源（防 fallback 拖慢）：
composer config -g repo.packagist false - 强制用 dist 包：
--prefer-dist，避免git clone卡在 SSH 或 GitHub API - 环境变量比命令行参数更可靠：
COMPOSER_PROCESS_TIMEOUT=1200能覆盖插件启动的子进程，--timeout=1200有时压根不生效 - 私有 Git 包？别指望镜像代理，得单独配 GitHub Token 或改 HTTPS 克隆地址
最容易被忽略的是：设了 process-timeout=0 还失败，那基本不是超时问题，而是内存不足（memory_limit 不够）或文件系统卡死（如 WSL2 下大量 symlink 解析）。先查 php -i | grep memory_limit，再确认 vendor 目录是否挂载在 NTFS 或远程卷上。
