退出码137表示进程被sigkill（信号9）强制终止，通常由内核oom killer触发，主因是内存超限；需通过dmesg、cgroup水位和容器限制等综合验证是否真为oomkilled。
Composer 进程被 kill（退出码 137）基本可以确定是被内核 OOM Killer 终止，不是 PHP 脚本报错或超时。关键要区分：是系统全局内存不足，还是 Composer 自身内存申请过大触发了限制。
确认是不是 OOMKilled
别急着改配置，先验证是否真被 OOM 杀掉：
- 查内核日志：
dmesg -T | grep -i "killed process"，重点看时间是否匹配 Composer 执行时段 - 查 Docker 事件（如果在容器里跑）：
docker events --since '2026-04-17T06:00:00' | grep -i oomkilled - 查进程退出码：
echo $?——运行完 Composer 后立刻执行，137 就是 SIGKILL，大概率 OOM - 注意：不是所有 137 都是 OOM，但没其他日志佐证时，优先按 OOM 排查
检查 PHP memory_limit 和系统可用内存
Composer 是 PHP 脚本，它的内存使用受两层控制：PHP 的 memory_limit 和宿主机物理内存 + Swap。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 临时提限最有效：
php -d memory_limit=3G /usr/local/bin/composer install，避免改全局配置影响其他服务 - 查当前 CLI 的限制：
php -r "echo ini_get('memory_limit');"，常见坑是 CLI 配置和 Web 配置不一致，CLI 默认可能只有 128M - 检查系统 Swap：
swapon --show，若无输出，说明没启用 Swap；fallocate -l 2G /swapfile && mkswap /swapfile && swapon /swapfile可快速补救 - Swap 不是万能的，SSD 上频繁 swap 会导致 Composer 极慢，只作兜底，不能替代调优
定位 Composer 内存暴涨的阶段
Composer 不同命令内存压力差异极大，update 比 install 高一个数量级，尤其含大量 dev 依赖或复杂约束时。
- 加
-v参数观察卡点：composer update -v，留意停在 “Resolving dependencies” 或 “Installing packages” 哪个环节开始卡顿或失败 - 禁用插件减负：
composer update --no-plugins，某些插件（如 phpstan、larastan）会在解析期间加载大量类，吃光内存 - 拆解依赖：用
composer depends --tree vendor/package-name查谁在拉取巨量间接依赖，考虑手动锁死版本或移除非必要 dev 包 - 注意：Composer 2.5+ 默认启用并行安装，但会显著增加峰值内存，可加
--no-parallel降压
容器环境要额外盯 tmpfs 和 cgroup 限制
在 Docker 或 docker-compose 里跑 Composer，容易忽略资源隔离带来的“假内存足、真受限”问题。
- 查容器内存上限：
docker inspect <container_id> | jq '.[0].HostConfig.Memory'</container_id>，若为 0 表示没设限；但deploy.resources.limits.memory在 Compose 文件里才生效 - 查 tmpfs 是否偷内存：
docker exec <container_id> mount | grep tmpfs</container_id>，没指定size=的 tmpfs 默认占宿主机内存 50%，和 Composer 抢资源 - 进容器看真实水位：
docker exec <container_id> cat /sys/fs/cgroup/memory/memory.usage_in_bytes</container_id>对比memory.limit_in_bytes，确认是否真触顶 - 别信
free -h，它显示的是宿主机视角；容器内看到的 “available” 是 cgroup 伪值，不可靠
真正难排查的不是 Composer 本身，而是它启动的子进程（比如 git clone、unzip、php scripts）或插件加载的分析器——这些不会出现在 php -d memory_limit 控制范围内，得靠 dmesg 和 cgroup 日志交叉印证。
