composer装包报network错误，90%是系统网络卡在dns解析、tcp连接或tls握手阶段；先运行ping packagist.org和curl -i https://packagist.org定位根因，再换dns、切热点、清缓存、调镜像。
Composer 装包报 network 错误，90% 不是 Composer 本身坏了，而是系统网络卡在 DNS 解析、TCP 连接或 TLS 握手阶段——别急着改 composer.json，先确认“能不能通网”。
看到 “Could not resolve host” 或 “Connection timed out” 怎么快速定位
这两类错误根本不在 Composer 控制范围内，是底层网络链路断了：
-
ping packagist.org返回unknown host→ DNS 解析失败，立刻换 DNS（比如8.8.8.8或114.114.114.114），比调http.timeout管用十倍 -
curl -I https://packagist.org卡住或报Failed to connect→ 防火墙、代理或 HTTPS 策略拦截，切手机热点一试便知 - 公司/学校网络常统一屏蔽
https://packagist.org和https://github.com，不是你配错了，是策略本身不放行
换镜像后还报错？检查缓存、配置覆盖和 URL 格式
镜像配置被绕过，比镜像本身失效更常见：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 必须执行
composer clear-cache，否则 Composer 仍可能从本地缓存读取已失效的地址 - 检查项目根目录
composer.json是否硬写了repositories→ 它的优先级高于全局镜像，会直接忽略你用config -g设的地址 - 清华镜像 URL 必须带末尾斜杠：
https://mirrors.tuna.tsinghua.edu.cn/composer/，少一个/就 404 - 验证是否真生效：
composer config -g repo.packagist（看全局），composer config repo.packagist（不加-g，看当前项目）
cURL error 28 或 “Connection reset by peer” 不是超时问题
这类错误看着像慢，其实是连接被中间设备（防火墙、NAT、旧 OpenSSL）主动掐断：
-
composer config -g http.timeout 600只影响 GET/packages.json这类元数据请求，不影响git clone—— 后者由 Git 自己控制超时 - 想让 Git 克隆不卡死：
git config --global core.sshCommand "ssh -o ConnectTimeout=30" - 强制跳过 git、改用 zip 下载（对 GitHub 包有效）：
composer config -g github-protocols https - CI/CD 中务必用环境变量固化：
COMPOSER_PROCESS_TIMEOUT=0，否则容器重启后配置丢失
SSL/TLS 握手失败（cURL error 35）怎么确认和绕过
网络通、DNS 解得开，但连不上 HTTPS，大概率是协议或证书链问题：
- 运行
php -r "print_r(openssl_get_cert_locations());"看default_cert_file是否存在且可读 -
composer config -g cafile应返回你指定的 PEM 文件路径；若为空，说明没配对，或证书格式不对（必须是 PEM，不能是 DER） - 临时绕过验证仅用于诊断：
COMPOSER_NO_SSL=1 composer install，若此时成功，100% 是证书链或协议问题——但执行完立刻删掉该环境变量 - Windows 用户还要检查
php.ini中curl.cainfo是否指向有效证书文件（如curl-ca-bundle.crt）
真正卡住的地方往往藏在 composer diagnose 的输出里，或者 curl -v 最后几行 —— 别只盯着错误关键词，要看它到底停在哪一层：DNS、TCP、TLS、HTTP 还是子进程执行。每个环节对应的参数和排查手段完全不同，混着调只会掩盖真实瓶颈。
