http-max-concurrent-downloads 是 Composer 2.2+ 唯一有效并发配置项，限制 HTTP 下载并发数，影响 install/update/require；parallel-downloads 已弃用，--concurrency 仅在其基础上微调，环境变量 COMPOSER_MAX_PARALLEL_HTTP_REQUESTS 优先级最高。
composer config -g http-max-concurrent-downloads 是唯一有效的并发配置项
Composer 2.2+ 中，http-max-concurrent-downloads 是唯一被官方支持且实际生效的全局并发控制参数。它直接限制 HTTP 请求池大小，影响 composer install、composer update 和 composer require 所有下载阶段。而 parallel-downloads 已被弃用——设了也白设，还可能让你误以为配置成功。
常见错误现象：执行 composer config -g parallel-downloads 8 后速度没变化，日志仍单行卡住；根本原因是该配置项在 2.2+ 版本中已被忽略，Composer 根本不读它。
- 确认是否生效：运行
composer config --global http-max-concurrent-downloads，输出应为数字（如10），不是null或空值 - 推荐值范围是
6–10：设10覆盖多数开发机带宽与磁盘 I/O 能力；设20极易触发镜像源 429 限流或本地file_put_contents(/tmp/): failed to open stream错误 - 必须搭配
composer --version ≥ 2.2：低于此版本（如2.1.14）该参数无效，先跑composer self-update
为什么 --concurrency 参数不起作用？
--concurrency 不是开关，而是微调器——它只在 http-max-concurrent-downloads 已设的前提下才生效。如果你没配全局参数，加 --concurrency=8 完全无效，日志里照样单行下载。
更常见的假象是：命令行加了参数，但终端输出始终停在某个包不动，进度条不跳变。这时大概率不是并发没开，而是外部瓶颈卡死了请求链：
- 镜像源限流：阿里云、腾讯云镜像在高峰时段对单 IP 并发 >12 会返回
429 Too Many Requests；换回官方源测试：composer config -g repo.packagist composer https://packagist.org - DNS 或 TLS 握手慢：用
strace -e trace=connect,write -p $(pgrep -f "composer install")看是否反复重试连接 - GitHub API 被限：没配 token 时每小时仅 60 次请求，报错
API rate limit exceeded；补上：composer config --global github-oauth.github.com <your-token>
并发只加速 download 阶段，别指望 update 也快
http-max-concurrent-downloads 对 composer install 效果明显，因为它是纯下载 + 解压流程；但 composer update 天然存在串行依赖图解析环节——必须等前一个包的元数据返回后，才能决定下一个要拉什么版本。所以即使并发设到 10，update 仍会卡在 “Resolving dependencies…” 或 “Loading composer repositories…” 上。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
实操建议：
- 日常开发尽量用
composer install（基于composer.lock），而非频繁update - 如果真要
update，先清缓存：composer clear-cache，再确保镜像源可用（composer config -g repo.packagist输出应为有效 URL） - 别信“并发让 update 快 3 倍”的说法——底层算法决定它不可能完全并行化
临时覆盖并发数：用环境变量，别信 COMPOSER_PARALLEL
临时改并发数最安全的方式是环境变量：COMPOSER_MAX_PARALLEL_HTTP_REQUESTS=6 composer install。注意变量名是 COMPOSER_MAX_PARALLEL_HTTP_REQUESTS，不是已废弃的 COMPOSER_PARALLEL——后者在 2026 年多数文档里还在误传，但实际不生效。
这个变量优先级高于全局 config，适合 CI 场景或临时调试：
- CI 中若遇到磁盘 I/O 瓶颈（如 GitHub Actions 默认 SSD 性能弱），可降为
4避免file_put_contents冲突 - macOS 或 Windows 上若报临时文件错误，立刻用该变量降到
6或8，比改全局 config 更快回滚 - 别混用：
COMPOSER_MAX_PARALLEL_HTTP_REQUESTS=6 composer install --concurrency=8以环境变量为准，CLI 参数会被忽略
真正卡住你的从来不是并发数设得够不够高，而是镜像源响应、DNS 解析、GitHub token 缺失这些前置条件没理清。并发只是放大器，不是万能解药。
