卡在“Resolving dependencies”且无响应时，大概率是网络协商问题；需用 composer install -vvv 查看 GuzzleHttp/cURL 底层日志，若停在 curl 命令后无 GET 输出，再结合 CURL_OPTIONS="--ipv4 --tlsv1.2" 和 tcpdump 抓包定位 TLS 握手或 DNS 阶段阻塞。
Composer install/update 卡在 “Resolving dependencies” 且无响应，怎么快速定位是网络协商问题？
直接看进程状态和日志层级：运行 composer install -v 或 composer update -vvv，如果卡在 Resolving dependencies 后长时间停住（>30秒），且终端光标静止、无新输出，大概率不是依赖逻辑卡住，而是底层 HTTP 请求在 TLS 握手或 DNS 解析阶段挂起——此时 -v 级别日志不够，必须用 -vvv。
关键判断依据：-vvv 会打印 GuzzleHttp 底层的 cURL 调用细节，包括 Host:、User-Agent:、SSL/TLS version: 和真实发起的 URL。若日志停在 Executing command (CWD): curl ... 后再无任何 GET https://repo.packagist.org/packages.json 类输出，基本可锁定是系统级网络协商阻塞。
如何让 Composer 强制走 IPv4 并禁用 TLS 1.3 避免握手僵死？
某些企业防火墙、老旧代理或中间设备对 IPv6 或 TLS 1.3 支持不完整，会导致 cURL 在 CONNECT 阶段无限等待。Composer 本身不提供开关，但可通过环境变量透传给底层 cURL：
- 强制 IPv4：
export CURL_OPTIONS="--ipv4"（Linux/macOS）或set CURL_OPTIONS=--ipv4（Windows CMD） - 降级 TLS：
export CURL_OPTIONS="--tlsv1.2"（禁用 TLS 1.3，避免 handshake failure silent hang） - 二者组合更稳妥：
export CURL_OPTIONS="--ipv4 --tlsv1.2"
注意：这些变量需在运行 composer 前设置，且仅影响当前 shell 会话；不要写进 composer.json 或全局 config，它们不生效。
为什么 composer config -g repo.packagist.org 改镜像后仍连不上？
常见误解：以为改了 packagist.org 的镜像地址就万事大吉。实际上，Composer 会先向 https://packagist.org/packages.json 发起 HEAD 请求校验可用性（即使你配了国内镜像），这个初始探测若失败，后续所有操作都会卡住。
验证方法：curl -I -v --tlsv1.2 --ipv4 https://packagist.org/packages.json 2>&1 | grep "HTTP/"。如果返回超时或 * Closing connection 后无状态码，说明问题出在出站链路，而非镜像配置本身。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
临时绕过校验（仅调试用）：composer config -g repo.packagist.org false，再手动设镜像：composer config -g repos.packagist composer https://mirrors.aliyun.com/composer/。但注意：这会让 Composer 完全跳过 packagist.org 可达性检查，生产环境慎用。
抓包确认是 TLS 握手卡在 Client Hello 还是 Server Hello？
当 -vvv 和 CURL_OPTIONS 仍无法突破时，必须抓包。推荐用 tcpdump（Linux/macOS）或 Wireshark（Windows），过滤目标域名：
tcpdump -i any -w composer.pcap host repo.packagist.org and port 443
然后复现卡住流程，停止抓包，用 Wireshark 打开 composer.pcap，按 ssl.handshake.type == 1 筛 Client Hello。如果看到 Client Hello 发出后，**没有对应的 Server Hello 返回**，且后续只有 TCP retransmission，说明问题在服务端不可达、中间设备拦截或 SNI 不匹配；如果 Server Hello 返回了但立刻断连，则可能是证书验证失败（如系统时间错误、CA 证书陈旧）。
特别注意：Docker 容器内抓包需加 --network=host 或用 nsenter，否则看不到宿主机 outbound 流量。
网络协商类 hang 最难 debug 的地方在于它不报错——没有 cURL error 7 或 500，只有沉默。盯住 -vvv 输出的最后一行、CURL_OPTIONS 的实际生效路径、以及抓包里第一个 SSL packet 的生死状态，比查 Composer 文档管用得多。
