parallel-downloads是Composer 2.2+官方内置并行能力，需全局配置（如composer config -g parallel-downloads 10）、配合国内镜像、--prefer-dist及清缓存才能生效；验证方式为运行composer install -vvv并观察日志是否同时出现多个Downloading行。
Composer 2.2+ 不需要第三方插件来实现并行下载——parallel-downloads 是官方内置能力，装了 hirak/prestissimo 反而会静默降级为串行，必须卸载。
怎么确认 parallel-downloads 是否真生效？
别只看配置有没有设，要验证它是否在跑：
- 执行
composer install -vvv，观察日志里是否**同时出现多个Downloading行**（不是一行接一行）；如果只有一条在动，说明并发被阻塞或未启用 - 运行
composer config -g parallel-downloads，输出应为数字（如10），若为空或报错，说明没设对（注意：必须加-g全局设置，项目级composer.json里写无效） - 低于 Composer 2.2 的版本不支持该配置，执行
composer --version确认，旧版先跑composer self-update --prefer-dist
为什么设了 parallel-downloads 还是卡在 Downloading？
并发数只是表象，真正卡住的往往是底层网络环节：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
php -m | grep curl必须有输出，否则 Composer 退化为fopen()串行拉取，且不报错 - DNS 解析慢、TLS 握手卡、镜像源响应差时，并发线程全堵在 connect 阶段，CPU 占用低、网络连接数极少
- 阿里云/腾讯云镜像在并发 >12 时容易返回
429 Too Many Requests，GitHub 源则可能触发403 rate limit exceeded（尤其没配github-oauth）
哪些参数必须和 parallel-downloads 一起用？
单独调高并发数几乎没用，它必须和这几项咬合工作：
-
--prefer-dist：强制走 ZIP 包而非 Git clone，否则并发下载的是几百 MB 的源码包，解压校验更慢；全局启用：composer config -g prefer-dist true - 国内镜像源：
composer config -g repo.packagist composer https://mirrors.tuna.tsinghua.edu.cn/composer/（别用已停更的 phpcomposer.com） - 清缓存：
composer clear-cache，否则旧元数据仍走境外源，镜像白配 - 关钩子：
--no-scripts --no-autoloader，避免 post-install-cmd 触发 npm install 或 redis flushdb 等重型操作
并发数设多少才安全？
不是越高越好，得看机器和网络实际承载力：
- 开发机推荐
8～10，CI 中可试12，但一旦出现file_put_contents(/tmp/): failed to open stream就立刻降到6 - Windows 用户注意杀毒软件实时扫描会拦截每个
file_put_contents调用，导致 vendor 写入骤降；macOS 上 APFS 的 fsync 开销也明显 - 临时覆盖可用环境变量：
COMPOSER_MAX_PARALLEL_HTTP_REQUESTS=6 composer install，比改全局配置更灵活
最常被忽略的一点：并行下载只作用于 HTTP 下载阶段，composer update 的依赖图计算、dump-autoload 的文件扫描、install 后的 symlink 创建，全是单线程——这些环节再怎么调并发也快不了。
