composer install卡在loading package information本质是tls握手阻塞或响应流卡住，常见于代理、dns污染、ipv6 fallback失败；下载依赖时假死因异步下载机制无进度输出；curl error 28因socket超时或http/2兼容问题；国内镜像失效多因全局配置未生效。
Composer install 卡在 loading package information 阶段
本质是 Composer 在初始化仓库元数据时，尝试从 packagist.org（或配置的镜像）拉取 packages.json 但连接超时或被重置。不是网络“没连上”，而是 HTTPS 请求卡在 TLS 握手或响应流阻塞——常见于企业代理、DNS 污染、IPv6 fallback 失败。
实操建议：
- 运行
composer config -g repo.packagist composer https://packagist.phpcomposer.com（国内旧镜像，已停用）→ 改用composer config -g repo.packagist composer https://packagist.org并加--no-cache强制绕过本地缓存 - 临时禁用 IPv6：Linux/macOS 下执行
sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1；Windows 可在网卡属性中取消勾选 IPv6 协议 - 检查是否被代理劫持：运行
curl -v https://packagist.org/packages.json | head -20，看是否返回 JSON 或卡在* Connected to packagist.org
下载依赖时进度条消失，composer update 停在某个包不动
这是 Composer 7+ 默认启用的「异步下载 + 并行解压」机制导致的视觉假死。它实际在后台下载 .zip 并校验 SHA256，但不输出进度——尤其当包体积大（如 laravel/framework）、磁盘 I/O 慢或杀毒软件扫描 ZIP 时更明显。
实操建议：
- 加
-vvv查看真实日志：composer update -vvv 2>&1 | grep -E "(Downloading|Extracting|Writing)"，确认是否真卡住 - 禁用并行下载：设置
COMPOSER_DISABLE_PARALLEL=1环境变量再运行命令 - 跳过 ZIP 解压直接用源码：在
composer.json中添加"preferred-install": {"*": "source"}，避免下载和解压 ZIP 的瓶颈
composer diagnose 显示 curl error 28 或 Operation timed out
这不是 Composer 自身 bug，而是 PHP cURL 扩展底层超时。默认 default_socket_timeout 是 60 秒，而 Packagist 的完整元数据响应可能超过这个值（尤其首次全量加载），触发 CURLOPT_TIMEOUT 中断。
实操建议：
- 临时调高超时：运行
php -d default_socket_timeout=300 /usr/bin/composer install - 检查 cURL 是否启用了 HTTP/2：某些旧版 OpenSSL + curl 组合下 HTTP/2 会 hang 住，加
composer config -g http-basic.github.com token xxx后再试，或设环境变量CURL_HTTP_VERSION=1.1 - 绕过 cURL 改用 stream：设置
COMPOSER_DISABLE_FUNCTIONS=curl_exec，强制 Composer 回退到 PHP stream context
使用国内镜像仍卡住，composer config -g repos.packagist 返回空
说明全局配置里根本没设镜像——很多人只改了项目级 composer.json 的 repositories，但 install 前 Composer 会先查全局元数据（packages.json），这一步不走项目配置，只认全局镜像。
实操建议：
- 确认镜像地址是否有效：访问
https://mirrors.aliyun.com/composer/packages.json看能否秒开并返回 JSON - 正确设置全局镜像：
composer config -g repos.packagist composer https://mirrors.aliyun.com/composer/（注意末尾斜杠不能少） - 删掉错误的配置项：
composer config -g --unset repos.packagist再重设，避免残留{"type": "composer", "url": null}这类无效配置引发静默失败
最常被忽略的是：Composer 的「卡住」往往分两层——第一层是元数据获取（全局配置决定），第二层是包下载（项目配置 + 网络环境共同影响）。调错层级，比如只换镜像却不调超时，问题照旧。
