确认并行下载是否真在运行，需观察composer install -vvv实时日志：若同一秒内多行“Downloading”或进度条跳跃式推进（如5/42→14/42→22/42），说明并发已激活；否则可能镜像未生效或DNS未绕过。唯一有效配置是http-max-concurrent-downloads（默认6），全局设为8～10最稳妥，设过高易触发临时文件竞争或镜像限流416错误；parallel-downloads已弃用。必须配合阿里云或清华源（https://mirrors.tuna.tsinghua.edu.cn/composer/）并执行composer clear-cache，且确保无项目级repositories覆盖全局配置。
怎么确认并行下载真在跑，而不是假提速
别只看命令加了参数，重点盯 composer install -vvv 的实时日志：如果同一秒内出现多行 Downloading https://mirrors.aliyun.com/...，或进度条从 (5/42) 跳到 (14/42) 再跳到 (22/42)，说明并发已激活；如果始终单行输出、卡在某个包不动，大概率是镜像没生效，或者本地 DNS 缓存没绕过。
该设 http-max-concurrent-downloads 还是 parallel-downloads
parallel-downloads 是 Composer 2.2 初期短暂用过的配置名，已在 2.2+ 正式弃用——设了也不生效，还容易让你误以为自己调高了并发。唯一有效的配置项是 http-max-concurrent-downloads，默认值通常是 6。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 全局设为 8～10（稳妥上限）：
composer config -g http-max-concurrent-downloads 8 - 设成 20 或更高，容易触发
file_put_contents(/tmp/): failed to open stream（临时文件竞争）或镜像站限流返回416 - 这个配置只对
composer install生效；composer update因依赖图需实时解析，底层仍有强串行逻辑
镜像源配错，并发再高也白搭
并发只是“同时发请求”，如果每个请求都卡在 DNS 解析或 TLS 握手，开 10 个线程等于 10 个排队窗口。必须确保：
- 全局换阿里云源：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 清华源新地址是：
https://mirrors.tuna.tsinghua.edu.cn/composer/（旧的packagist.phpcomposer.com已停用） - 换源后必须清缓存：
composer clear-cache，否则旧元数据仍尝试回源 - 验证是否生效：
composer config -g repo.packagist输出应为完整 HTTPS URL，不能是null或空值
CI/CD 中最容易被忽略的并发陷阱
项目级 composer.json 中存在 "repositories" 字段，会完全覆盖全局镜像配置——你设了 http-max-concurrent-downloads 10，但实际请求全走境外源，根本没进镜像。
- 要么删掉项目级
repositories，要么显式把镜像 URL 写进去，并加{"packagist.org": false} - 某些私有镜像不支持
Range请求头，强行高并发会返回416 Requested Range Not Satisfiable - Docker 环境中若禁用了
opcache.enable_cli，会导致依赖解析变慢，间接拖垮并发吞吐
