composer 2.1+ 原生支持并行 http 下载而非多线程，需版本≥2.1、配置http-max-concurrent-downloads=8、切换阿里云镜像并清缓存，通过composer install -vvv观察多行downloading及进度跳变验证生效。
Composer 本身不支持多线程下载，所谓“启用多线程”是常见误解；真正能提速的是并行 HTTP 请求（基于 curl_multi），且仅在 Composer 2.1+ 中原生支持，必须满足版本、镜像、配置三者对齐才生效。
确认 Composer 版本是否支持并行下载
低于 2.1 的版本（如 2.0.x 或 1.x）压根不识别并行相关配置，设了 http-max-concurrent-downloads 或 parallel-downloads 都无效。
- 运行
composer --version，输出必须类似Composer version 2.2.22或更高 - 若版本过低，执行
composer self-update --prefer-dist升级 - 升级后务必运行
composer clear-cache，否则旧缓存可能干扰新逻辑
用对配置项：http-max-concurrent-downloads 而非 parallel-downloads
Composer 2.2+ 已弃用 parallel-downloads，它不再起作用——即使设了也不报错，但完全无效。唯一被官方文档认可的并发控制项是 http-max-concurrent-downloads。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 全局设置推荐值：执行
composer config -g http-max-concurrent-downloads 8 - 设为 10 多数机器会触发阿里云镜像限流或临时文件竞争，报错
file_put_contents(/tmp/): failed to open stream - 该配置只影响
composer install；composer update因需实时解析依赖图，仍存在不可绕过的串行阶段
换镜像源 + 清缓存 + 绕 DNS 才算真正落地
并发只是“同时发请求”，如果每个请求都卡在 DNS 解析、TLS 握手或源站响应上，开 8 个等于 8 个排队窗口。
- 全局切阿里云镜像：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 切源后必须清缓存：
composer clear-cache，否则仍尝试回源 - 验证是否生效：
composer config -g repo.packagist应输出完整 URL，不是null或空值 - Docker 或 CI 环境中，需在构建早期就配好镜像，避免每次构建都重拉元数据
验证并行是否真在跑，别信“设了就快”
不能只看命令有没有加参数，关键看日志输出是否动态跳变。
- 执行
composer install -vvv - 若看到多行
Downloading https://几乎同时出现，或进度显示Downloading (7/42)并快速跳到(12/42)，说明并发已激活 - 如果始终只有一条
Downloading在动，CPU 占用低、网络连接数极少，那并发其实被阻塞了——大概率是镜像没生效或 DNS 未绕过 - 若日志停在
Generating autoload files或某个post-install-cmd上，调并发毫无意义，瓶颈根本不在下载层
最容易被忽略的点：并发配置只对 --prefer-dist（默认）生效，对 --prefer-source（git clone）完全无效；而很多私有包或开发中未打 tag 的包会 fallback 到 source 模式，此时再高的并发数也无济于事。
