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 还是秒杀？大概率栽在这几个细节上：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
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 文件的权限和挂载位置。
