答案是容器内执行composer install被Killed由OOM Killer触发，非Composer或PHP崩溃；需查dmesg确认，根本原因是cgroup内存限制而非free显示的空闲内存，COMPOSER_MEMORY_LIMIT无效，php -d memory_limit必须前置且路径正确，install比update内存开销小得多。
容器里执行 composer install 被 Killed 是 OOM Killer 干的
不是 Composer 崩溃，也不是 PHP 报错，终端只显示 Killed 就是内核直接干掉了进程。Docker 默认内存限制宽松但不为零，而轻量级镜像（比如 php:8.2-cli-slim）常运行在资源受限环境（CI runner、边缘节点、本地测试机），composer install 解压+写文件+生成 autoloader 的过程会瞬时吃掉 500MB+ 内存，触发 OOM Killer。
验证方式：sudo dmesg -T | tail -20，看到类似 Out of memory: Kill process 12345 (php) score 876 就坐实了。
- 别信
free -h显示“还有 1G”，容器 cgroup 限制可能只有 512MB —— 查cat /sys/fs/cgroup/memory/memory.limit_in_bytes -
COMPOSER_MEMORY_LIMIT=2G完全无效：它只是 Composer 自己的软开关，不改 PHP 进程上限 -
php -d memory_limit=2G composer install也救不了命：PHP 启动后实际能用多少，由 cgroup 决定，不是 ini 设置说了算
php -d memory_limit 放错位置就等于没写
命令顺序错了，PHP 根本收不到参数。写成 composer install -d memory_limit=2G，Composer 会把 -d 当作子命令忽略；写成 composer install --php-params="-d memory_limit=2G" 是旧版 hack，v2+ 已废弃。
- 正确写法必须是：
php -d memory_limit=2G composer install - Ubuntu 系统上
which composer返回的是 shell wrapper（/usr/bin/composer），它会吞掉-d参数 → 改用绝对路径：php -d memory_limit=2G /usr/bin/composer install - PowerShell 用户注意：
memory_limit=2G必须加引号，否则-被识别为 PowerShell 参数：php -d "memory_limit=2G" composer install
挂载卷 + composer install = 权限和 inode 双重暴击
在轻量容器里挂载宿主机代码目录（-v $(pwd):/app）再跑 composer install，除了 UID/GID 不匹配导致 Permission denied，还容易因小文件爆炸耗尽 inode。
-
df -i查 inode 使用率，/var/lib/docker/overlay2或根分区IUse%超过 95% 就会卡住甚至被 kill - Composer 解包一个包可能生成几十个文件（含 .gitkeep、LICENSE、tests/ 目录），vendor 里几百个包轻松干掉 50 万 inode
- local-path-provisioner 创建的 PV 默认属主是
root:root，而容器内 PHP 进程以www-data（UID 33）运行 →chown -R 33:33 /data1才能写入
composer install 和 composer update 的内存消耗根本不在一个量级
install 是按 composer.lock 精确还原，开销可控；update 要跑 SAT 求解器暴力尝试所有版本组合，内存增长是指数级的。轻量容器里只要看到 Resolving dependencies 卡住，基本就是 update 在爆内存。
- CI/CD 或部署脚本里，永远用
composer install --no-dev --optimize-autoloader，禁用update - 真要升级依赖，缩小范围：
composer update monolog/monolog guzzlehttp/guzzle，避免全量重算 - 本地调试时，先确认
composer.lock存在且已提交 —— 缺失它会导致install自动 fallback 成update
