Composer install/update 被 kill 很可能是 OOM Killer 所致，表现为终端仅显示“Killed”；可通过 dmesg -O | grep -i "killed process" 或查看系统日志确认；临时启用 Swap 可缓解但非根治，更有效的是使用 --no-dev、-o、COMPOSER_MEMORY_LIMIT=-1 及升级 Composer 2.x。
Composer install/update 时进程被系统 kill，大概率是 OOM Killer 干的
Linux 内核在物理内存严重不足时，会触发 OOM Killer（Out-Of-Memory Killer），主动选择并终止占用内存最多的用户进程——composer 正好常因依赖解析、类加载、插件初始化等行为吃掉几百 MB 甚至上 GB 内存，首当其冲被 kill -9。此时终端只显示 Killed，无堆栈、无错误详情，就是典型 OOM 表现。
如何确认确实是 OOM 而非其他错误
别猜，直接查系统日志：
- 运行
dmesg -O | grep -i "killed process"，若看到类似Out of memory: Kill process 12345 (php) score 894 or sacrifice child，就坐实了 -
grep -i "out of memory" /var/log/syslog（Debian/Ubuntu）或/var/log/messages（CentOS/RHEL）也能捕获记录 - 注意：不是所有环境都开启
dmesg时间戳，加-T可看本地时间（需 root）
Swap 空间能缓解但不能根治，且有陷阱
临时加 Swap 确实能让 Composer “多喘几口气”，但必须清楚它的代价和限制：
- 没 Swap 的 VPS（如很多 Docker 默认环境、轻量云实例）会直接触发 OOM，加 1–2GB Swap 是最快止损手段
- 用
sudo fallocate -l 2G /swapfile && sudo mkswap /swapfile && sudo swapon /swapfile可快速启用（重启后失效） - 但 Swap 在 SSD 上会加剧写入磨损；在 HDD 上会让 Composer 变得极慢（IO 成瓶颈），有时卡住比被 kill 更难受
- PHP 自身的内存限制（
memory_limit）和 Composer 的--no-scripts --no-plugins参数，比依赖 Swap 更有效
真正降低 Composer 内存占用的实操方法
治标不如治本。以下操作可让 composer install 内存峰值下降 40%–70%：
- 加
--no-dev（生产环境必加），跳过require-dev解析和 autoload 生成 - 用
--optimize-autoloader或简写-o，生成静态映射而非动态扫描，减少 PHP 启动时内存压力 - 设环境变量
COMPOSER_MEMORY_LIMIT=-1（慎用），绕过 Composer 自带的内存保护，把控制权交还给系统——前提是已调高memory_limit - 升级到 Composer 2.x（
composer self-update --2），其依赖求解器重写后内存更可控，老版本 1.x 在大型项目中极易爆掉
COMPOSER_MEMORY_LIMIT=-1 composer install --no-dev -o
这行命令在 CI 或低配服务器上很常见，但要注意：它不解决根本内存不足，只是把“谁来 kill”从 Composer 切换到内核——所以仍要配合 --no-dev 和足够 Swap 或物理内存。
真正麻烦的是那些隐式吃内存的场景：比如 post-install-cmd 脚本里加载了全量 Laravel 应用，或者某自定义 Plugin 做了全目录反射。这种时候，Killed 不是配置问题，而是代码设计问题。
