Composer 2.1+ 已原生支持并发下载，无需安装 prestissimo；提速只需换镜像、清缓存、正确设置 http-max-concurrent-downloads（推荐值8），且仅对 install 有效。
别装 hirak/prestissimo —— 它已彻底失效，还会破坏 lock 文件、触发 file_put_contents(/tmp/): failed to open stream 错误。 Composer 2.1+ 原生支持并发下载，所谓“Parallel 插件”是过时概念；真要提速，只靠三件事：换镜像、清缓存、设对并发参数。
确认 Composer 版本是否支持原生并发
低于 2.1 的版本压根不识别任何并发配置，设了 parallel-downloads 或 http-max-concurrent-downloads 都白搭。
- 运行
composer --version，输出必须是类似Composer version 2.2.22才合规；若显示1.x或2.0.x，立刻执行composer self-update --prefer-dist - 升级后验证是否真生效：运行
composer install -v，看到类似Downloading (7/42)这种数字动态跳变（不是一行卡住、再跳一行），才说明并发已启动 - 若仍单行打印、长时间停在某个包，大概率是镜像响应慢或 DNS 卡顿，不是并发没开
用对并发参数：只认 http-max-concurrent-downloads
parallel-downloads 在 Composer 2.2+ 中已被弃用，官方文档不再提及；继续设它不会报错，但也不起作用。当前唯一被认可、实际控制 HTTP 请求池大小的配置项是 http-max-concurrent-downloads。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 全局设为 8（多数机器稳态上限）：
composer config -g http-max-concurrent-downloads 8 - 设成 10 以上容易触发阿里云镜像限流（
429 Too Many Requests）或本地临时文件竞争（failed to open stream） - 该配置仅对
composer install有效；composer update因需实时解析依赖图，元数据拉取仍是串行，无法靠此提速
换镜像源 + 清缓存，否则并发只是假象
并发只是“同时发请求”，如果每个请求都卡在 DNS 解析、TLS 握手或跨洋路由上，开 10 个并发和 1 个实际耗时差不多，甚至更差（重试叠加）。
- 切到阿里云镜像：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 清空旧缓存：
composer clear-cache（否则可能复用过期的 packagist.org 缓存） - CI 或 Docker 构建中，务必提前在
Dockerfile里执行换源命令，避免每次构建都重新拉源 - GitHub 包多的项目，记得配 token：
composer config -g github-oauth.github.com YOUR_TOKEN，否则每小时仅 60 次 API 调用，根本撑不起并发
真正卡点常不在下载层——比如日志停在 Generating autoload files 或某个 post-install-cmd 上，调并发毫无意义。先用 composer install -v 看清真实瓶颈，再决定动哪一步。
