Composer默认不支持限速，需通过http-max-concurrent-downloads降并发和http-downloader.rate-limit限单连接速率（≥2.5.0）协同实现；仅调一项效果差，且限速不解决解析、解压等本地耗时问题。
Composer 默认不设下载限速，跑满带宽是常态，不是 bug —— 但你完全可以用 http-downloader 配置主动压低并发和单连接速率。
为什么 Composer 会吃光带宽？
它默认启用并行下载（http-max-concurrent-downloads），且每个连接不做流控。尤其在 CI/CD 或共享网络环境里，十几路并发拉包很容易打满上行/下行链路，影响其他服务或同事上网。
- 现象：执行
composer install时网卡监控显示持续 90%+ 占用，SSH 卡顿、网页加载变慢 - 本质：Composer 的 HTTP 下载器（cURL 或 PHP stream）本身不带限速逻辑，全靠系统 TCP 层和网络设备调度
- 注意：
parallel-downloads已废弃，新版只认http-max-concurrent-downloads，设了旧参数无效
怎么给 Composer 下载加限速？
核心是两步：降并发 + 限单连接速率。不能只调一个，否则效果打折。
- 设最大并发数：
composer config -g http-max-concurrent-downloads 4（推荐 2–6，别设 1，太慢；别超 8，易触发镜像限流） - 加单连接限速（需 Composer ≥ 2.5.0）：
composer config -g http-downloader.rate-limit 500k（单位支持k/m，如200k、1m） - 验证是否生效：
composer config -g http-downloader应输出类似{"rate-limit":"500k"} - 限速值不是越小越好：低于
100k可能导致部分镜像（如清华）因超时重试，反而拖更久
限速后仍卡住？检查这几个隐性干扰项
限速只管下载阶段，不解决解析、解压、写 autoload 这些本地 CPU/IO 密集型操作。如果“卡”在 Resolving dependencies 或 Installing dependencies 后半段，和带宽无关。
-
COMPOSER_MEMORY_LIMIT=-1：PHP 内存不足会导致依赖解析反复失败重试，看着像卡，实为计算阻塞 - Xdebug 开着：
php -d xdebug.mode=off $(which composer) install临时禁用，能提速 5 倍以上 -
vendor/残留 +composer.lock版本陈旧：删干净再composer install --no-cache，避免重复校验和解压 - 镜像 URL 少斜杠（如
https://mirrors.aliyun.com/composer）：会 404 回退到官方源，此时限速失效，且请求被 GitHub 限频
限速配置不是万能的，它只约束 HTTP 下载行为；真正影响整体耗时的，往往是 PHP 环境配置和本地磁盘性能——尤其是 SSD 读写慢、autoload 生成卡在 symlink 创建时，这些地方没日志提示，最容易被当成“网络问题”反复折腾。
