composer获取packages失败主因是ipv6解析超时且fallback延迟，推荐用composer_no_ipv6=1临时禁用ipv6（composer 2.2+原生支持），或配置use-ipv4=true全局/项目级生效，再配合阿里云镜像源提升稳定性。
Composer 获取 packages 失败，大概率不是网络“慢”，而是卡在 IPv6 解析阶段——它尝试连接 ::ffff:185.199.108.153 这类映射地址却超时，且不及时 fallback 到 IPv4。直接禁用 IPv6 解析比等它自动回退快得多。
用 COMPOSER_NO_IPV6=1 临时禁用（推荐）
这是 Composer 2.2+ 原生支持的开关，生效快、无副作用：
- Linux/macOS：
COMPOSER_NO_IPV6=1 composer install - Windows PowerShell：
$env:COMPOSER_NO_IPV6="1"; composer install - Windows CMD：
set COMPOSER_NO_IPV6=1 && composer install - 该变量只影响当前命令，不污染环境，适合 CI/CD 或临时调试
全局启用 use-ipv4 配置项（长期项目适用）
写入配置后，所有后续命令默认走 IPv4，避免每次加前缀：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 当前项目生效：
composer config use-ipv4 true（写入项目级composer.json的config字段） - 全局生效：
composer config -g use-ipv4 true（写入~/.composer/config.json） - 注意：Composer 1.x 不识别此配置，旧版本必须用
COMPOSER_NO_IPV6=1 - 执行后无需清缓存，但已有
composer.lock中的源 URL 不会自动更新
换镜像源 + 强制解析为 IPv4（最稳组合）
国内直连 packagist.org 极易因 IPv6 路由异常失败，镜像源本身已做协议适配，再配合 DNS 层控制更可靠：
- 切阿里云镜像：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 验证是否真走 IPv4：
ping mirrors.aliyun.com，输出应为类似118.31.67.205的地址，而非240e::开头 - 若仍解析出 IPv6，可手动写入
/etc/hosts（Linux/macOS）或C:\Windows\System32\drivers\etc\hosts（Windows）：118.31.67.205 mirrors.aliyun.com - 不建议改
/etc/gai.conf或系统 DNS 优先级——影响面太广，仅限运维级调整
为什么 CURL_IPRESOLVE=4 有时无效？
它依赖 libcurl 版本和 PHP 编译方式，容易被忽略的几个硬性条件：
- PHP 必须启用 cURL 扩展，且
curl_version()['features'] & CURL_VERSION_IPV6返回非零值（说明编译时支持 IPv6，但我们要绕过它） - libcurl 版本需 ≥ 7.19.4；低于此版本该选项被忽略
- Composer 2.2+ 默认使用 cURL 驱动，但若你启用了自定义 HTTP 客户端（如 Guzzle），
CURL_IPRESOLVE就不生效 - 比起环境变量，
COMPOSER_NO_IPV6=1是 Composer 自己解析并跳过 IPv6 地址的逻辑，更底层、更可控
真正关键的不是“让 Composer 学会选路”，而是让它根本不去查 IPv6 地址。环境变量和配置项是轻量解法，镜像源是兜底保障——三者组合用，基本覆盖所有 IPv6 引发的 packages 获取失败场景。别在 php.ini 里改 curl.ipresolve = 4，那会影响所有 PHP curl 调用，得不偿失。
