卡住需定位阶段：downloading是http超时，调http-basic-timeout；cloning是git问题，改https或配token；resolving是依赖冲突，用composer why-not；优先换阿里云镜像并清缓存，中断后精准清理vendor/autoload.php和vendor/composer/再重试。
卡住不是“等一等就好”，而是某个环节已失败或阻塞，必须定位阶段、切断残留、换通路重来。
看最后输出的 URL 判断卡在哪一环
运行 composer install -vvv，盯住最后一行日志：
- 停在
Downloading https://packagist.org/packages.json或类似Downloading https://...—— 是 HTTP 请求卡死，重点调http-basic-timeout（Composer 2.2+）或http.timeout（旧版），不是process-timeout - 停在
Cloning into '/path/to/vendor/xxx'—— 是git clone卡住，得配 Git 超时或改用 HTTPS 克隆，process-timeout才管用 - 停在
Resolving dependencies—— 根本不是网络问题，是 SAT 求解器在暴力回溯版本冲突，该跑composer why-not查阻断链
换镜像源比加 timeout 更快见效
阿里云镜像地址现在仍是有效的：https://mirrors.aliyun.com/composer/，但必须配对执行两步：
- 设源：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/（注意末尾/不能少） - 清缓存：
composer clear-cache，否则仍可能从损坏的本地缓存读取
验证是否生效：composer config -g repo.packagist 应输出完整 JSON；再跑 composer install -vvv，日志里必须出现 mirrors.aliyun.com，否则 fallback 仍在走官方源。
中断后 vendor/ 里藏着“假成功”文件
Composer 没有断点续传，中断后残留的破损 ZIP、截断的 installed.json 或卡死的临时目录会持续干扰后续执行：
- 别直接删整个
vendor/—— 这会导致autoload.php缺失，后续命令全报错 - 精准清理：
rm vendor/autoload.php && rm -rf vendor/composer/，再跑composer dump-autoload && composer install - 若仍报
Failed to extract或Content-Length mismatch，说明缓存已坏，必须composer clear-cache
Git 类包绕过镜像，得单独处理
只要 composer.json 里有 "type": "git" 的依赖（比如开发分支引用），Composer 就会直连 GitHub，不走镜像：
- 优先改用 HTTPS 克隆：
"https://github.com/user/repo.git"替代"git@github.com:user/repo.git" - 配 GitHub Token 防 API 限流：
{"github-oauth": {"github.com": "xxx"}}写进~/.composer/auth.json - 给 Git 加超时（Linux/macOS）：
git config --global core.sshCommand "timeout 300 ssh"
真正麻烦的从来不是“要不要多等几分钟”，而是那些看似完整、校验却失败的包文件——它们不会自己消失，也不会被 --retry 覆盖，得手动清掉缓存和 vendor 中间态才真正重启。
