Composer install 在1GB VPS上OOM主因是默认加载全依赖图+插件且PHP无内存限制，导致进程超1.2GB被OOM killer终止；根治需组合--no-dev、运行时设memory_limit（如512M）、clear-cache三者缺一不可。
为什么
在 1GB VPS 上直接 OOM？
不是 Composer 本身太重，而是它默认启动时会加载完整依赖图并启用所有插件（比如
、
等），同时 PHP 进程无内存上限，一碰到带大量
的项目（如 Laravel、Symfony 全栈模板），PHP 进程轻松吃掉 1.2GB+ 内存，触发 Linux OOM killer 杀掉进程，报错通常是：
（无具体 PHP 错误）或
。
加
真的有用吗？
有用，但只是“止血”，不是根治。它跳过包作者写的推荐扩展（
字段），不下载、不解析那些可选依赖，能减少约 5–10% 的内存峰值和解析时间。但它不影响
和
的解析逻辑，对大依赖树（比如
带几十个子依赖）几乎没缓解作用。
必须跟在
或
后面，写成
它不改变锁文件，也不跳过自动加载生成，只是省掉「建议提示」阶段
如果你根本不需要开发依赖，优先用
，比
降内存更明显
怎么调 PHP 内存限制才真正生效？
别改
—— Composer 启动时可能走 CLI 配置，而很多 VPS 的 CLI
跟 Web 的不是同一个，且改系统配置需要重启或权限。最稳的方式是运行时覆盖：
Composer 2.9.6
Composer 2.9.6 是 PHP 生态中高效、稳定的依赖管理工具。此版本在性能与兼容性上进一步优化，改进了依赖解析算法，提升大型项目中的安装与更新速度。它支持并行下载任务，显著减少等待时间，并增强了与私有仓库及镜像源的交互稳定性。同时修复了多项命令行交互与内存使用相关的缺陷，确保在复杂依赖关系下依然可靠运行。无论是新项目初始化还是现有系统维护，Composer 2.9.6 都能为开发者提供流畅、精准的依赖管理体验。
下载
用
（路径用
确认）
如果还是爆，降到
或
，但注意：低于 256M 可能连基础解析都失败
避免用
（无限制），这会让 OOM killer 更早介入，不如设一个略高于实际峰值的值
临时生效，不影响其他 PHP 任务，也无需 root 权限
还有三个必须做的轻量级优化
这些不花额外内存，但能显著降低 Composer 的计算压力：
确保已运行
，旧缓存（尤其含大量 zip 包元数据）会拖慢解析并增加内存驻留
用
：跳过开发依赖 + 生成扁平化
，减少后续 autoload 查找开销
如果只是部署，别跑
—— 它要重新 resolve 整个依赖树；只用
，靠
精确还原，快且稳
真正卡住的点往往不是某个开关，而是把
、内存参数、缓存清理三者漏掉一个。比如只加
却没关
，内存照样爆。
composer installsymfony/flexlaravel/installerrequire-devKilledPHP Fatal error: Allowed memory size of XXX bytes exhausted--no-suggestsuggestrequirerequire-devphpunit/phpunit--no-suggestcomposer installcomposer updatecomposer install --no-suggest--no-dev--no-suggestphp.iniphp.iniphp -d memory_limit=512M /usr/bin/composer installwhich composer384M256M-1composer clear-cachecomposer install --no-dev --optimize-autoloaderautoload_classmap.phpcomposer updateinstallcomposer.lock--no-dev--no-suggestdev