Composer install CPU跑满的根源是默认并行下载未合理配置，应通过http-max-concurrent-downloads设为6～8，并同步限制Docker cgroup内存与CPU资源以确保稳定。
composer install 为什么 CPU 还是跑满？
不是并发数没限制住，而是你根本没关掉它——Composer 2.2+ 默认就启用并行下载，但默认只开 3 个并发连接，看起来不猛，可一旦遇到慢源、重试、TLS 握手卡顿，这些连接会“堵死”在 I/O 上，PHP 进程持续占用 CPU 等响应，结果就是 composer install 卡住、CPU 持续 90%+、内存悄悄涨到爆。
真正有效的并发控制：只改 http-max-concurrent-downloads
这是 Composer 2.2+ 唯一被代码层硬编码识别的并发开关。其他名字（比如 parallel-downloads）要么已废弃，要么只在极老版本里起作用，别信。
-
composer config -g http-max-concurrent-downloads 6—— 全局生效，推荐值6～8；设10以上容易触发镜像源限流（如阿里云/腾讯云返回429 Too Many Requests） - 临时覆盖用：
COMPOSER_MAX_PARALLEL_HTTP_REQUESTS=6 composer install（注意不是COMPOSER_PARALLEL，该变量自 2.2 起失效） -
--concurrency=8参数只是“微调”，前提是上面那个配置已生效；单独加它毫无作用
并发数调低 ≠ 安全，还得防 I/O 和内存雪崩
设成 1 确实不占 CPU，但你会回到 Composer 1 时代的龟速体验；更危险的是，低并发 + 高内存 + 无超时控制，反而更容易在慢网络下 hang 死。
- 下载卡住？先看是不是 DNS 或 TLS 不稳：
strace -e trace=connect,write -p $(pgrep -f "composer install")观察是否反复重连 - 内存爆了？别改
php.ini，直接加环境变量：COMPOSER_MEMORY_LIMIT=2G composer install（-1表示不限制，慎用） - macOS/Windows 上报
file_put_contents(/tmp/): failed to open stream？说明临时文件竞争，立刻把并发降到6或8
Docker 环境下必须同步配 cgroup 内存限制
你在宿主机上设了 COMPOSER_MEMORY_LIMIT=2G，但容器本身只分配了 512M 内存，那 Composer 还是会在 OOM Killer 的刀口上跳舞。
- Docker Compose 中必须写：
deploy: resources: limits: memory: 2g - 否则即使 PHP 层允许用 2G，Linux cgroup 也会在
512M时直接 kill 掉进程，错误日志里只显示Killed，没有堆栈 - CPU 同理：
cpus: '1.0'要配合http-max-concurrent-downloads使用，否则高并发下载照样抢光单核
