根本不用换镜像，问题出在composer自身的ipv6解析逻辑：它优先尝试不可达的ipv6地址（如240e::xxx）并超时30秒，而非镜像不支持双栈；最有效解法是设composer_no_ipv6=1强制全程走ipv4。
根本不用换镜像，问题出在 Composer 自己的 IPv6 解析逻辑上——它卡在等不可达的 ::ffff:0:0/96 地址超时，而不是镜像不支持双栈。
为什么 composer install 卡在 Resolving dependencies 或 Downloading
不是镜像慢，也不是你网络差。Composer 默认拿到 DNS 的 AAAA 记录后，会优先用 IPv6 连接（比如 240e::xxx），但很多本地网络或 CDN 节点实际不响应 IPv6 TLS 握手，导致单次连接卡 30 秒；上百个包叠加，就是几分钟没动静。
- 验证方法：运行
curl -v https://mirrors.aliyun.com/composer/packages.json，如果看到* Trying 240e::xxx并长时间停住，就是 IPv6 捣乱 - 注意：
ping mirrors.aliyun.com返回 IPv4 地址（如118.31.67.205）才正常；返回 IPv6 地址说明系统 DNS 配置已偏向 IPv6 - 阿里云、腾讯、中科大等镜像本身都监听 IPv4 和 IPv6，所谓“双栈镜像”是伪命题——客户端行为才是瓶颈
最轻量有效的解法：COMPOSER_NO_IPV6=1 或 CURL_IPRESOLVE=4
这两个环境变量直接干预 Composer 底层请求行为，不改系统配置、不换镜像、不碰 DNS，生效快且无副作用。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
COMPOSER_NO_IPV6=1：Composer 2.2+ 原生支持，强制跳过所有 IPv6 地址解析，全程走 IPv4，推荐首选 -
CURL_IPRESOLVE=4：更底层，影响所有基于 cURL 的 PHP 请求（包括 Composer 内部调用），兼容性更广，旧版 Composer 也适用 - 使用方式统一：执行前加前缀，例如
COMPOSER_NO_IPV6=1 composer install或CURL_IPRESOLVE=4 composer update - 别设成全局环境变量（如
export），只在当前命令生效，避免干扰其他工具
镜像源配置的细节陷阱
换国内镜像能提速，但若配置错误，IPv6 问题反而被掩盖或加剧。
- 阿里云镜像地址末尾必须带斜杠：
https://mirrors.aliyun.com/composer/（少斜杠会导致重定向失败，触发额外 DNS 查询，放大 IPv6 问题） - 全局设置命令是：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，不是packagist.org - 项目级配置优先级高于全局，检查
composer.json中是否有硬编码的repositories字段，它会绕过镜像设置 - 私有 Git 仓库（如
git@xxx或https://github.com/xxx）不走镜像，IPv6 问题仍存在，需单独处理
http.timeout 和 process-timeout 别混用
它们管的是不同阶段，设错等于白调。
-
http.timeout控制每次 HTTP 请求的连接+读取总时长（单位秒），解决卡在Downloading的核心参数，建议设为300～600：composer config -g http.timeout 600 -
process-timeout管整个命令生命周期（如composer install从开始到结束），防脚本卡死，设太大会掩盖真实问题，建议300～1800 - 两者都得设，但
http.timeout才是治标关键；只调process-timeout不解决单个包下载卡顿 - 别信
composer config -g timeout——这个键不存在，Composer 不认
真正麻烦的不是超时值本身，而是网络路径中某一段（DNS 解析、TLS 握手、中间代理）对 IPv6 的非对称响应——它可能只在特定包、特定时刻触发，所以单纯拉长超时只是兜底，绕过 IPv6 才是根治。
