卡在Loading composer repositories是元数据拉取失败，需确认镜像URL末尾带/、执行composer clear-cache清缓存、用curl验证镜像返回合法JSON；Resolving dependencies卡住则是本地SAT求解器穷举版本组合，与网络无关。
卡在 Loading composer repositories 或 Resolving dependencies 阶段，本质是 Composer 在拉取 packages.json 元数据时被掐断——这不是包下载失败，而是连源站的根清单都拿不全。必须区分 DNS、TLS、HTTP 连接三阶段，调对参数才有效。
为什么 http.timeout 不管用？
因为元数据加载走的是「仓库发现流程」，它先解析 packagist.org 域名，再发 HTTPS 请求获取 packages.json，最后才开始下载 ZIP。这个过程受三重限制：
-
default_socket_timeout（PHP 底层）：控制 DNS 解析 + TCP 连接 + TLS 握手，单位秒，默认常为60；若低于你设的http.timeout，cURL 会提前报curl: (28) Operation timed out -
http.timeout（Composer 2.x）：只覆盖「已建立连接后的 HTTP 请求」，即首字节等待 + body 传输，不包含 DNS 和 TLS 阶段 - 镜像源配置未生效：比如
composer config -g repo.packagist写错 URL 格式（漏斜杠）、或项目级repositories字段硬编码了packagist.org，直接绕过镜像
composer diagnose 报 curl error 28 怎么快速定位
运行 composer diagnose -v，重点看两行输出：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 若出现
Checking platform settings: OK但卡在Checking git settings后，说明是 DNS 或 TLS 层问题（如公司代理拦截证书、WSL2 的 resolv.conf 错误） - 若显示
Downloading https://repo.packagist.org/packages.json然后中断，才是 HTTP 层超时，此时才该调http.timeout - 执行
php -i | grep default_socket_timeout，确认值 ≥ 300；若为60，立刻改：在php.ini里加default_socket_timeout = 600，然后重启 CLI 环境
国内用户最稳的三步操作
别只调 timeout，先切断对 packagist.org 的直连依赖：
- 全局换镜像：运行
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/（注意结尾斜杠和composer类型） - 清空顽固缓存：执行
composer clear-cache，并手动删掉~/.composer/cache/repo/https---mirrors.aliyun.com-composer/目录（metadata 缓存不随clear-cache删除） - 禁用回源机制：在项目
composer.json顶部加"repositories": [{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}]，同时删掉所有含"packagist.org"的repositories条目——否则 Composer 仍会 fallback 到官方源重试
元数据加载失败往往卡在「看不见的底层」：DNS 轮询、TLS 1.3 兼容性、CA 证书链缺失。比起无休止调高 timeout，优先确保 default_socket_timeout 足够、镜像 URL 正确且无回源残留，才能真正跳过那几十秒的盲等。
