Composer install 在1GB VPS上OOM主因是默认加载全依赖图+插件且PHP无内存限制，导致进程超1.2GB被OOM killer终止；根治需组合--no-dev、运行时设memory_limit（如512M）、clear-cache三者缺一不可。
为什么 composer install 在 1GB VPS 上直接 OOM？
不是 Composer 本身太重，而是它默认启动时会加载完整依赖图并启用所有插件（比如 symfony/flex、laravel/installer 等），同时 PHP 进程无内存上限，一碰到带大量 require-dev 的项目（如 Laravel、Symfony 全栈模板），PHP 进程轻松吃掉 1.2GB+ 内存，触发 Linux OOM killer 杀掉进程，报错通常是：Killed（无具体 PHP 错误）或 PHP Fatal error: Allowed memory size of XXX bytes exhausted。
加 --no-suggest 真的有用吗？
有用，但只是“止血”，不是根治。它跳过包作者写的推荐扩展（suggest 字段），不下载、不解析那些可选依赖，能减少约 5–10% 的内存峰值和解析时间。但它不影响 require 和 require-dev 的解析逻辑，对大依赖树（比如 phpunit/phpunit 带几十个子依赖）几乎没缓解作用。
-
--no-suggest必须跟在composer install或composer update后面，写成composer install --no-suggest - 它不改变锁文件，也不跳过自动加载生成，只是省掉「建议提示」阶段
- 如果你根本不需要开发依赖，优先用
--no-dev，比--no-suggest降内存更明显
怎么调 PHP 内存限制才真正生效？
别改 php.ini —— Composer 启动时可能走 CLI 配置，而很多 VPS 的 CLI php.ini 跟 Web 的不是同一个，且改系统配置需要重启或权限。最稳的方式是运行时覆盖：
- 用
php -d memory_limit=512M /usr/bin/composer install（路径用which composer确认） - 如果还是爆，降到
384M或256M，但注意：低于 256M 可能连基础解析都失败 - 避免用
-1（无限制），这会让 OOM killer 更早介入，不如设一个略高于实际峰值的值 - 临时生效，不影响其他 PHP 任务，也无需 root 权限
还有三个必须做的轻量级优化
这些不花额外内存，但能显著降低 Composer 的计算压力：
- 确保已运行
composer clear-cache，旧缓存（尤其含大量 zip 包元数据）会拖慢解析并增加内存驻留 - 用
composer install --no-dev --optimize-autoloader：跳过开发依赖 + 生成扁平化autoload_classmap.php，减少后续 autoload 查找开销 - 如果只是部署，别跑
composer update—— 它要重新 resolve 整个依赖树；只用install，靠composer.lock精确还原，快且稳
真正卡住的点往往不是某个开关，而是把 --no-dev、内存参数、缓存清理三者漏掉一个。比如只加 --no-suggest 却没关 dev，内存照样爆。
