composer install -v 会强制执行DNS解析→TCP连接→TLS握手→HTTP请求→响应解析全流程，精准定位卡点：如“Connection timed out”卡TCP，“SSL certificate problem”卡TLS，“无输出静默”多因IPv6 fallback。
先跑 composer install -v，别急着改配置——它会暴露真实卡点在哪一环，比看报错文字快十倍。
怎么用 composer install -v 定位卡在 DNS、TCP 还是 TLS
默认 composer install 不输出网络细节，加 -v 后强制走完整链路：DNS 解析 → TCP 连接 → TLS 握手 → HTTP 请求 → 响应解析。你能直接看到停在哪：
-
Failed to connect to repo.packagist.org port 443: Connection timed out→ 卡在 TCP 连接，大概率是防火墙或代理拦截 -
SSL certificate problem: unable to get local issuer certificate→ TLS 握手失败，不是镜像问题，是 CA 证书缺失或企业中间人代理 - 没任何输出、长时间静默 → 很可能是 IPv6 fallback 导致的“假卡顿”，不是真慢
为什么 ping packagist.org 和 curl -I https://packagist.org 必须一起跑
这两条命令能快速区分 DNS 失败和连接拦截，比翻 Composer 日志高效得多：
-
ping packagist.org返回unknown host→ DNS 解析失败，换系统 DNS（如8.8.8.8）比调http.timeout有用十倍 -
curl -I https://packagist.org卡住或报Failed to connect→ 防火墙、代理或 HTTPS 策略拦截，切手机热点一试便知 - 公司/学校网络常统一屏蔽
https://packagist.org和https://github.com，不是你配错了，是策略本身不放行
IPv6 fallback 导致“Resolving dependencies” 卡住几分钟
这不是网络慢，是 Composer 默认先尝试 IPv6 地址，超时（通常 1–3 秒）再 fallback 到 IPv4。上百个包叠加，就是几分钟无响应：
- 验证方法：
curl -v https://packagist.org 2>&1 | grep "Connected to"，如果看到类似Connected to packagist.org (2a03:2880:...)的 IPv6 地址且后续卡住，基本就是它 - 临时绕过：
CURL_IPRESOLVE=4 composer install - 长期方案：全局启用 IPv4 优先，比如配清华镜像源：
composer config -g repos.packagist composer https://mirrors.tuna.tsinghua.edu.cn/composer/（注意末尾必须有/）
镜像配完没生效？缓存和配置优先级在捣鬼
换了阿里云或清华源还报错，大概率不是镜像不行，而是旧缓存或项目级配置覆盖了你的设置：
- Composer 2.9.6 必须执行
composer clear-cache，否则仍可能从本地缓存读取已失效的地址 - 检查是否项目根目录
composer.json里硬写了repositories→ 它的优先级高于全局镜像，会直接忽略你用config -g设的地址 - 验证是否真生效：
composer config -g repo.packagist（看全局），composer config repo.packagist（不加-g，看当前项目）
最隐蔽的坑是：vendor/autoload.php 生成失败却没报错——部分包下载成功，部分因超时静默跳过，Composer 回滚时不会提示“xx 包未写入”，而是生成一个残缺的 autoload.php，文件存在但为空或只有几行注释。判断依据是 composer show 报 Could not find package in a package repository。
