Composer update在低内存服务器上OOM的根本原因是依赖求解阶段加载过多包元数据到内存；应禁用预加载（--no-suggest、--no-plugins）、设COMPOSER_MEMORY_LIMIT=-1、收紧版本约束并可切换为backtracking求解器。
Composer update 在低内存服务器（如 1GB 或更低）上经常因 OOM（Out of Memory）被系统 kill，根本原因是默认启用的依赖解析器会加载大量包元数据到内存。这不是网络慢或磁盘问题，是 PHP 进程真实爆内存。
为什么 composer update 会吃光内存？
Composer 2.x 默认启用 --prefer-dist 和并行下载，但核心瓶颈在依赖求解阶段：它需将所有匹配版本的 composer.json 元数据（包括 require、conflict、provides 等字段）全部载入内存做 SAT 求解。一个中等规模项目（含 50+ 直接依赖）可能触发数百个包的元数据拉取与解析，PHP 进程轻松突破 512MB。
-
composer install通常没问题，因跳过求解，只按composer.lock下载 -
composer update必须重跑求解，尤其加了--with-all-dependencies或修改了require-dev后更危险 - PHP 的
memory_limit设置对 Composer 不生效——它用的是进程整体内存，不是 PHP 内存池
临时提内存不如关掉元数据预加载
最有效的方法不是调大 memory_limit，而是让 Composer 少加载东西。关键开关是禁用「提前获取所有候选包的完整 composer.json」行为：
- 加
--no-suggest：跳过建议包（不影响求解，但省 IO 和解析开销） - 加
--no-plugins：禁用插件（某些插件会额外抓元数据） - 强制使用
--prefer-dist（默认已启用，但显式写上更稳） - 最关键：设置环境变量
COMPOSER_MEMORY_LIMIT=-1并配合--ignore-platform-reqs减少约束维度（慎用，仅限你清楚扩展缺失影响时）
实操命令示例：
Comprehensive Three.js 3D graphics reference
下载
详细的 Three.js 3D 图形参考，涵盖场景设置、相机、几何体、材质、光照、动画、控制器、加载器、数学工具和调试。
COMPOSER_MEMORY_LIMIT=-1 composer update --no-suggest --no-plugins --prefer-dist --ignore-platform-reqs
composer.json 层面的长期优化
频繁在低配机跑 update，说明开发流程有隐患。应从源头减少求解复杂度：
- 避免宽泛版本约束，例如把
"monolog/monolog": "^2.0"改为锁定小版本"^2.10"，缩小可选包范围 - 删掉不用的
require-dev包，特别是那些带大量子依赖的测试工具（如phpunit/phpunit全家桶） - 用
replace或conflict显式排除已知冲突包，比靠求解器推导更快 - 定期运行
composer normalize（需安装ergebnis/composer-normalize），消除格式差异导致的无效重解析
实在不行，换求解策略
Composer 2.2+ 支持切换依赖求解器。默认的 libui 求解器内存友好但有时卡住；备用的 backtrack 更保守，适合低内存场景：
composer config solver backtracking
之后再跑 update。注意：该配置会写入项目 composer.json 的 config.solver 字段，团队协作时需同步确认。
真正卡住的点往往不在「怎么多给点内存」，而在「让它别一次性全拿过来」——元数据流式处理、约束收紧、求解器降级，这三步做完，1GB 机器跑 update 就不再需要 swap 或重启 PHP 进程了。
