Composer install 显示“Killed”是 Linux OOM Killer 终止 PHP 进程所致，并非 Composer 报错；可通过 dmesg 查证，临时加 swap 或用 COMPOSER_MEMORY_LIMIT=-1 --no-plugins --no-dev 等降低内存峰值。
为什么 Composer install 会显示 “Killed” 而不是具体错误？
Linux 内核在内存严重不足时，会触发 OOM Killer（Out-Of-Memory Killer），它会选择一个进程强制终止，并输出 Killed —— 这不是 Composer 报错，而是系统行为。你不会看到 PHP 错误或 Composer 异常堆栈，composer install 就突然退出，终端只留一个冰冷的 Killed。
确认是不是 OOM 导致的 Killed
运行 dmesg -O | grep -i "killed process"，如果输出类似：
Killed process 12345 (php) total-vm:2845678kB, anon-rss:1234567kB, file-rss:0kB
就基本坐实了。注意看括号里是 php，说明 Composer 启动的 PHP 进程被干掉了。
- 别只看
free -h，swap 可能已耗尽但未启用 - 容器环境（如 Docker）要查宿主机内存，或检查
docker stats中的 memory limit - 某些 VPS（如 DigitalOcean 1GB 基础款）默认无 swap，极易触发 OOM
快速修复：临时加 swap 或限制 Composer 内存占用
不改配置、不删依赖，立刻让 composer install 跑完的组合操作：
- 创建 1GB 临时 swap 文件：
sudo fallocate -l 1G /swapfile && sudo chmod 600 /swapfile && sudo mkswap /swapfile && sudo swapon /swapfile - 限制 Composer 使用单线程 + 禁用插件减少内存峰值：
COMPOSER_MEMORY_LIMIT=-1 composer install --no-plugins --no-scripts - 如果项目含大量 dev 依赖（如测试工具、PHPStan），先装生产依赖：
composer install --no-dev
COMPOSER_MEMORY_LIMIT=-1 是告诉 Composer 别自己设内存上限（PHP 默认值可能更宽松），但前提是系统真有可用内存或 swap。
Docker 或 CI 环境下怎么防住？
CI（GitHub Actions、GitLab CI）和 Docker 默认内存极小，且通常禁用 swap。关键动作是：
- Docker 运行时加内存限制宽松些：
docker run --memory=2g --memory-swap=2g ...（避免--memory-swap=0） - GitHub Actions 中避免在
ubuntu-latest上直接跑composer install，改用composer install --no-interaction --optimize-autoloader --no-progress - 在
composer.json的config段加上："process-timeout": 0, "fxp-asset": {"enabled": false}（后者可省掉 asset plugin 的额外开销）
真正麻烦的是嵌套场景：Docker in Docker（如自建 runner）、低配云函数环境——这时候得提前精简 require-dev，或者把 vendor 构建步骤挪到构建机而非运行时。
