Composer进程被Killed基本是Linux OOM Killer所致；需运行dmesg -O | grep -i "killed process"确认，若swapon --show无输出则须立即创建Swap文件并设chmod 600、chown root:root，同时配合--no-dev、-o、COMPOSER_MEMORY_LIMIT=512M等参数降低内存峰值。
Composer 进程被 Killed，基本可以断定是 Linux 内核的 OOM Killer 干的——不是 Composer 崩溃，而是进程被强制终止。它发生在内存彻底耗尽、系统自救阶段，比 Allowed memory size exhausted 更早、更底层，改 PHP 的 memory_limit 无效。
怎么确认真是 OOM Killer 杀的？
别猜，直接查内核日志：
- 运行
dmesg -O | grep -i "killed process"，看到类似Out of memory: Kill process 12345 (php) score 894就是铁证 - 或者查系统日志：
grep -i "out of memory" /var/log/syslog（Ubuntu/Debian）或/var/log/messages（CentOS/RHEL） - 顺手跑下
swapon --show和free -m：如果Swap行 total 是 0，说明压根没 Swap，OOM 几乎必然发生
为什么加了 Swap 还被 Kill？
Swap 文件建了、swapon 也执行了，但依然被杀，大概率是权限或路径踩了坑：
-
sudo chmod 600 /swapfile必须执行——Linux 要求 Swap 文件权限严格为 600，漏掉这步就白搭 -
sudo chown root:root /swapfile确保所有权正确 - 别把
/swapfile放在/tmp、/var/tmp或 Docker volume 挂载目录下；推荐用/swapfile（根目录）或/var/_swap_/swapfile - 验证是否真生效：
swapon --show必须有输出，且free -m中Swap行的total> 0
不靠 Swap，怎么压 Composer 内存峰值？
Swap 是兜底手段，真正降内存得从 Composer 自身行为入手：
- 加
--no-dev：跳过require-dev解析和 autoload-dev 生成，省掉 30%–50% 内存 - 加
--optimize-autoloader（或简写-o）：生成静态 classmap，避免运行时扫描 - 设环境变量
COMPOSER_MEMORY_LIMIT=512M（不建议设-1，低配机上反而容易触发 OOM） - 用
--prefer-dist：优先下 zip 包而非 git clone，减少进程和内存开销 - 升级到 Composer 2.x：依赖求解器重写后内存更可控，老版本 1.x 在 Laravel/Docker 场景下极易爆掉
CI/CD 或容器里被 Kill 怎么办？
GitHub Actions、GitLab CI、Docker 默认限制内存且不暴露 kill 日志，现象常是静默退出（exit code 137）：
- CI 脚本开头加
export COMPOSER_MEMORY_LIMIT=512M（比php -d更稳，Composer 自己识别） - 加
--no-progress --verbose暴露最后执行的命令，定位卡点 - Docker 启动时显式分配内存：
docker run --memory=2g ...，否则容器内即使宿主机内存足，也会被 cgroup 限死 - WSL2 或 Docker for Mac 下挂载 NTFS 路径时，autoload 扫描 symlink 极慢——临时用
composer install --no-autoloader，再手动composer dump-autoload --optimize
最易被忽略的一点：Swap 开机自动启用必须写进 /etc/fstab，否则重启后失效，下次跑 composer update 又回到原点。而 swapon --show 为空，就是你该动手建 Swap 的明确信号。
