composer install/update 被 kill 是因依赖解析内存峰值超 1.5gb 触发 linux oom killer；应设 composer_memory_limit=1g、加 –no-dev –optimize-autoloader、禁用并行安装，并定期更新 lock 文件、精简 dev 依赖、避免通配符版本。
Composer install 或 update 时进程被系统 kill
这是典型的内存溢出（OOM）现象，Linux 内核主动终止了 composer 进程，错误信息里通常带 Killed 字样（不是 PHP 报错，不显示堆栈），dmesg -T | tail 能看到类似 Out of memory: Kill process 12345 (php) score 892... 的日志。
- 根本原因不是 Composer 本身写得差，而是其依赖解析器在处理大型项目（如 laravel + 多个 dev 依赖 + lock 文件过期）时会构建庞大的依赖图，PHP 进程峰值内存常超 1.5GB
- 默认配置下，
composer install比update更容易触发 OOM，因为要校验并解压全部包（尤其是含大量 assets 或扩展的包，如laravel/framework、symfony/symfony） - 共享主机、CI 环境（如 github Actions 默认 2GB）、或未调优的 docker 容器（
--memory=1g）最常中招
限制 Composer 内存使用但不失败
别用 php -d memory_limit=-1 composer.phar install —— 这反而加速被 kill。正确做法是主动限流，让 Composer “慢但不死”：
- 用
COMPOSER_MEMORY_LIMIT环境变量硬性截断：运行前执行export COMPOSER_MEMORY_LIMIT=1G（注意单位是G或M，不能写1024M，否则识别失败） - 搭配
--no-dev和--optimize-autoloader：生产环境部署必须加，跳过 dev 依赖解析可降内存 40%+；--optimize-autoloader延后类映射生成，避免早期爆内存 - 禁用并行解包：加
--disable-tls无用，真正有效的是COMPOSER_DISABLE_PARALLEL=1，强制串行安装，减少瞬时内存尖峰
从源头降低依赖解析压力
很多团队只在报错后才优化，其实 composer.json 结构和 lock 文件状态才是关键变量：
-
composer.lock过期越久，update时需计算的版本组合爆炸式增长 —— 每月至少跑一次composer update --dry-run检查是否可安全更新 - 删掉没用的
require-dev包，特别是全量安装的测试工具（如phpunit/phpunit9.x 依赖树极深）；改用require-dev+config.platform.php锁定低版本 PHP 运行时，避免解析高版本兼容路径 - 避免通配符版本约束：
"monolog/monolog": "^2.0"比"monolog/monolog": "*"安全得多；后者会让 Composer 尝试所有已发布版本来满足依赖，内存直接拉满
Docker 或 CI 环境的特殊处理
本地能跑不等于容器里能跑，cgroup 限制比 PHP memory_limit 更底层：
- Docker 启动时务必加
--memory=2g --memory-swap=2g，否则即使 PHP 限 1G，内核仍可能因 swap 不足 kill 进程 - GitHub Actions 中，
ubuntu-latest默认只有 7GB 内存但被 runner 自身占用近 2GB，建议显式指定runs-on: ubuntu-22.04并在 step 开头加free -h和cat /sys/fs/cgroup/memory/memory.limit_in_bytes排查真实可用内存 - 若用
docker build阶段运行 Composer，优先用multi-stage：build 阶段用大内存容器装依赖，final 阶段只复制vendor/，彻底规避运行时内存问题
最易被忽略的一点：Composer 的 OOM 往往发生在解压后加载 autoloader 的瞬间，此时 PHP 已接管内存管理，COMPOSER_MEMORY_LIMIT 失效。这时候只能靠提前裁剪依赖或换更轻量的自动加载策略（比如放弃 PSR-4 全局扫描，改用 classmap 显式声明）。