composer进程被“killed”是linux oom killer触发所致，需通过dmesg -o | grep -i "killed process"确认，并检查swapon --show是否有输出、swap文件权限是否为600且归属root、路径是否避开/tmp等受限目录。

Composer 进程被 “Killed” 基本就是 Linux OOM Killer 干的，不是 PHP 报错，也不是网络超时——查 dmesg 才算真正开始排查。

怎么确认是 OOM 而不是其他问题

终端只显示 Killed，没堆栈、没错误行？别猜，直接验证：

• 运行 dmesg -O | grep -i "killed process"，看到类似 Out of memory: Kill process 12345 (php) 就实锤了
• 补查系统日志：grep -i "out of memory" /var/log/syslog（Ubuntu/Debian）或 /var/log/messages（CentOS/RHEL）
• 运行 swapon --show，如果无输出，说明 Swap 根本没启用——这是低配 VPS 上 80% 的“Killed”根源
• 注意：php -d memory_limit=2G composer install 没用，OOM 是内核在进程级杀的，PHP 还没来得及报 Allowed memory size exhausted

Swap 启用了但还是被 Kill，常见漏项有哪些

Swap 文件建了、swapon 也执行了，结果 composer update 还是秒杀？大概率栽在这几个细节上：

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

• chmod 600 /swapfile 必须执行，权限不对（比如 644）会导致内核拒绝使用
• chown root:root /swapfile，非 root 所有者可能被忽略
• 路径不能在 /tmp、/var/tmp 或 Docker volume 挂载点下（overlayfs 不支持 swapfile）
• 验证是否真生效：free -m 中 Swap 行的 total 值必须 > 0；swapon --show 必须有输出
• fallocate 在 ext3/NFS 上可能失败，改用 dd if=/dev/zero of=/swapfile bs=1M count=2000

为什么加了 Swap 还卡住甚至更慢

Swap 不是万能解药，它只是把“被 kill”换成“等得想砸键盘”：

• SSD 上：频繁换页会加剧写入磨损，长期不建议
• HDD 上：IO 成瓶颈，composer install 可能卡十几分钟不动，比被 kill 更难忍
• 容器环境（Docker/K8s）：默认禁用 Swap，docker run --memory=1g 限制下，即使宿主机有 Swap，容器也用不到
• 真正降内存峰值的操作更有效：--no-dev（跳过 dev 包）、-o（优化 autoloader）、--prefer-dist（不 git clone）、升级到 Composer 2.x

Composer CPU 拉满 + 内存暴涨却不报错，可能是循环依赖

这不是 OOM，但表现相似：终端卡死、top 看 php 进程 CPU 95%+、内存每秒涨 50MB+，dmesg 却没 OOM 记录——大概率是 SAT 求解器陷入循环依赖死锁：

• 快速验证：composer update --dry-run -v，最后几行反复出现同一组包路径（如 a → b → a）
• 实锤命令：composer depends vendor/package --tree，若输出含闭环（如 myorg/core ← myorg/api ← myorg/core），就是它
• 别用 --ignore-platform-reqs 或 --force，它们会让求解器尝试更多非法组合，延长死锁时间
• 破环只有三种办法：抽离公共契约包、运行时依赖注入（删掉 composer.json 里的硬 require）、或把反向依赖移到 require-dev

OOM 排查最易被忽略的点：以为 COMPOSER_MEMORY_LIMIT 或 php -d memory_limit 能拦住 OOM —— 它们拦不住内核级 kill。真正要盯的是 swapon --show 输出、dmesg 日志、以及 Swap 文件的权限和挂载位置。