根本原因是linux oom killer触发，因物理内存与swap总和不足导致；必须先启用swap（如sudo fallocate -l 1g /swapfile && sudo mkswap /swapfile && sudo swapon /swapfile），再配合composer_memory_limit限制和--no-dev等参数优化。
Composer 进程被系统直接 Killed，基本可以断定是 Linux OOM Killer（Out-Of-Memory Killer）干的——不是 Composer 崩溃，而是内核强制杀掉了它。根本原因只有一个：物理内存 + Swap 不足以支撑 Composer 解析依赖树时的瞬时峰值内存占用。临时调高 PHP 内存限制（比如 php -d memory_limit=2G）没用，因为 Killed 发生在进程级，早于 PHP 的 Allowed memory size exhausted 报错。
为什么 swapon --show 没输出就代表必须加 Swap
OOM Killer 触发前，系统会先尝试回收内存；若连 Swap 都没有，回收失败后就会直接杀进程。很多低配 VPS（尤其是 1GB 内存以下的 CentOS/Ubuntu）默认不启用 Swap，swapon --show 执行后空返回就是铁证。这时候光改 memory_limit 或设 COMPOSER_MEMORY_LIMIT 都是徒劳——PHP 还没来得及报错，进程就被内核干掉了。
- 检查命令：
swapon --show或free -m | grep Swap - 没输出？立刻建 Swap，别犹豫
- Swap 大小建议：1GB（内存 ≤ 1GB 时）或 2GB（内存 2GB 但 Composer 依赖多）
- 注意：
fallocate在某些旧版 ext3 或 NFS 文件系统上可能失败，可换用dd if=/dev/zero of=/swapfile bs=1M count=2000
sudo swapon /swapfile 后仍被 Kill 的常见漏项
Swap 文件建好了、也启用了，但 Composer 还是被 Kill？大概率是权限或挂载方式不对。Linux 对 Swap 文件有严格要求：必须是普通文件（不能是符号链接）、权限必须为 600、且不能位于某些受限挂载点（如 /tmp 或容器 overlayfs 下）。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 确认权限：
sudo chmod 600 /swapfile（漏掉这步是高频错误） - 确认所有权：
sudo chown root:root /swapfile - 避免路径陷阱：不要放在
/tmp、/var/tmp或 Docker volume 挂载目录下；推荐/swapfile根目录或/var/_swap_/swapfile - 验证是否真生效：
sudo swapon --show必须有输出，且free -m中 Swap 行的total值 > 0
如何让 Swap 开机自动启用（避免重启后失效）
手动 swapon 只对当前会话有效。服务器重启后 Swap 消失，下次跑 Composer 又会触发 Killed。必须写入 /etc/fstab 才算真正落地。
- 追加配置行：
echo "/swapfile none swap sw 0 0" | sudo tee -a /etc/fstab - 验证语法：
sudo swapon --verify /swapfile（部分新版系统支持） - 测试加载：
sudo swapoff /swapfile && sudo swapon /swapfile，再free -m确认 - 注意：如果
/swapfile路径不对（比如你建的是/var/_swap_/swapfile），fstab 里必须写完整路径
COMPOSER_MEMORY_LIMIT 和 PHP -d memory_limit 的真实作用边界
这两个参数只控制 Composer 自身 PHP 进程的内存上限，不影响 OOM Killer 的触发逻辑。它们的作用是「提前退出」，而非「防止被 Kill」。
-
COMPOSER_MEMORY_LIMIT=512M composer install：Composer 解析到 512MB 时主动报错退出，不会触发 OOM Killer -
php -d memory_limit=2G composer.phar install：把 PHP 层内存上限拉高，让 Composer 能跑更久，但若系统总内存（含 Swap）仍不足，照样被 Kill - 生产部署建议组合使用：
COMPOSER_MEMORY_LIMIT=1G composer install --no-dev --prefer-dist，既控内存又减包量 - CI 环境慎用
-1：不限制内存在容器中极易引发宿主机 OOM，CI 日志里看到Killed往往就是这个原因
Swap 是治标，精简依赖才是治本。但当项目已成型、composer.json 无法轻易删包时，Swap 就是最快速有效的保命手段——只是别忘了，Swap 文件的 I/O 延迟会让 Composer 安装变慢，这不是 bug，是磁盘代替内存的必然代价。
