最直接线索是-vvv日志末尾2–3行：停在Resolving dependencies表明DNS或域名不可达；Downloading表明HTTP层卡住；Executing command表明子进程阻塞；Generating autoload files后无响应则属文件系统或PHP配置问题。
看 -vvv 输出的最后一行，别猜
Composer 卡住时，最直接的线索藏在详细日志末尾。运行 composer install -vvv 或 composer update -vvv，**只盯最后 2–3 行输出**，它明确告诉你卡在哪一层：
- 停在
Resolving dependencies：不是超时，是 DNS 解析失败或 packagist.org 域名根本不可达；试dig packagist.org或换 DNS（如114.114.114.114） - 停在
Downloading https://...：HTTP 层卡住，http-basic-timeout或镜像源响应慢；检查是否连得上该 URL（curl -I -m 30 https://mirrors.aliyun.com/composer/） - 停在
Executing command (CWD: ...)：子进程（如git clone、unzip、php artisan）卡死；process-timeout或COMPOSER_PROCESS_TIMEOUT才管用 - 停在
Generating autoload files后无响应：跟网络无关，是文件系统（如 WSL2 的 symlink）、PHP 配置（APCu CLI 未启用）或磁盘 IO 慢导致
http-basic-timeout 和 process-timeout 到底谁该调
这两个参数互不替代，设错一个等于白调：
-
http-basic-timeout：控制单次 HTTP 请求（含 TLS 握手、首字节等待、body 传输）最大秒数，默认仅 60 秒；下载大包（如laravel/frameworkdist）或镜像首字节延迟高时最先触发；建议设为300～600 -
process-timeout：控制整个命令从 start 到 end 的总耗时上限，默认 300 秒；它包含解压、运行post-install-cmd、生成 autoloader 等所有步骤；大项目跑脚本容易超，推荐设为1200 -
http-basic-timeout在 Composer 2.2+ 才支持；旧版本只能靠--timeout（等价于process-timeout）硬扛，或换镜像
CI/CD 中超时问题必须组合出手
光加 timeout 在 CI 里基本没用，因为环境更“脆”：
- 必须配国内镜像：
composer config -g repos.packagist.org.url https://mirrors.aliyun.com/composer/ - 强制用 dist 包：
--prefer-dist，避免git clone卡在 SSH 或 GitHub API - 环境变量比命令行参数更可靠：
COMPOSER_PROCESS_TIMEOUT=1200能覆盖插件启动的子进程，而--timeout=1200可能漏掉 - 检查硬编码仓库：
composer.json里是否写了"url": "https://packagist.org"这类直连配置，会绕过镜像设置 - WSL2 用户注意：
composer install在 NTFS 挂载区生成 symlink 极慢，可临时export COMPOSER_HOME=/tmp/.composer换到 Linux 原生路径
别忽略 PHP 底层和系统级限制
Composer 是 PHP 脚本，它的超时还受下层制约：
- PHP 的
default_socket_timeout（php.ini）默认常为 60 秒，cURL 请求可能先于此超时；需同步调高 -
memory_limit不足会导致解析依赖时直接崩溃，而非报 timeout；CI 中建议设为-1或2G - 公司/校园网若拦截 HTTPS 请求，
ping packagist.org可能通但curl -I https://packagist.org失败；此时必须配代理或换网络 - GitHub API 调用卡在
https://api.github.com/repos/xxx/zipball/？没配github-oauthtoken 就会被限流，auth.json里补上才有效
真正卡点往往不在 Composer 配置本身，而在它调用的 Git、cURL、PHP 运行时或宿主系统——-vvv 日志末尾那行字，就是唯一可信的入口。
