Composer 默认不支持多线程下载，其本质是串行 cURL 请求；常见报错实为单请求失败后的重试或缓存污染所致，需同步清缓存与换镜像并调高两个 timeout 参数。
Composer 默认不支持多线程下载，所谓“多线程报错”其实是误判
Composer 本身没有内置多线程下载机制——它用的是串行 cURL 请求，一次只下 1 个包。你看到的 Connection refused、Content-Length mismatch 或卡在 Loading composer repositories，都不是并发导致的，而是单请求失败后被反复重试或缓存污染引发的连锁反应。
常见误导场景：CI 环境里并行跑多个 composer install 实例，或误以为 --prefer-dist 启用了并发；实际只是 PHP 进程并行，每个进程内部仍是单线程下载。
- Composer 2.x 完全不提供
--parallel或类似参数，所有“加速并发”方案都是外部封装（如concurrently脚本），极易触发 token 冲突或镜像限流 - 真正影响下载节奏的是
http-basic-timeout和process-timeout，不是线程数 - 若看到
curl error 7+ 多个包几乎同时失败，大概率是 DNS 或代理全局抖动，不是 Composer 在“开多线程”
报 Content-Length mismatch 时别 retry，先清缓存
这个错误本质是本地缓存文件损坏：cURL 下了一半断了，Composer 却把残缺 zip 当成完整包复用，校验时发现字节数对不上。此时重试只会反复加载坏文件。
- 必须执行
composer clear-cache，确认~/.composer/cache/files/目录为空后再重试 - 加
--no-cache参数可跳过缓存读取，但不解决已写入的坏文件 - 阿里云等镜像偶尔同步滞后，也会返回旧版
dist.url指向已失效的 zip，换源后仍需清缓存
企业内网遇到 Connection refused 怎么办
这不是 Composer 配置问题，而是中间设备（防火墙、代理、SSL 解密网关）主动拒绝连接。错误关键词直接指向网络策略层。
- 先验证基础连通性：
ping packagist.org→ 若返回unknown host，立刻改系统 DNS（如设为8.8.8.8） - 确认是否用了镜像：
composer config -g repo.packagist输出必须是https://mirrors.aliyun.com/composer/（注意是 HTTPS） - 临时绕过 TLS 校验仅用于定位：
composer config -g secure-http false+composer config -g cafile /dev/null（仅调试，勿留生产） - 某些网关会拦截 SNI，可强制 IPv4：
CURL_IPRESOLVE=4 composer install（Linux/macOS）
超时类错误必须同时调高两个 timeout 参数
process-timeout 和 http-basic-timeout 是两道独立闸门：前者管整个命令生命周期，后者管单次 HTTP 请求。只调一个，另一道仍会卡死。
- 永久生效：
composer config -g process-timeout 1800+composer config -g http-basic-timeout 300 - 临时生效（如 CI）：
composer install --timeout=1200 --http-basic-timeout=240 -
http-basic-timeout=0表示不限时，但可能无限挂起，不推荐 - 单纯加 timeout 不如换镜像有效——等得再久，连不上 packagist.org 还是白等
最常被忽略的一点：清缓存和换镜像必须一起做。只换源不清缓存，Composer 仍会从旧失败记录里读取已被污染的 URL 和 hash；只清缓存不换源，下次还是连不上。两者是绑定动作，少一个就白忙。
