OOM Killer 杀死进程是因内存峰值超512MB，需组合使用--no-plugins、--no-dev、--prefer-dist等参数降内存，并配1GB swap+vm.swappiness=10兜底；线上部署必须用install而非update。
内存不足时 composer install 直接 OOM 被 kill 怎么办
512MB 内存跑 composer install 大概率失败，不是超时，是系统直接 Killed process php (pid 1234) —— Linux OOM Killer 干的。Composer 默认会加载所有插件、解析完整依赖图、缓存大量对象，峰值内存轻松突破 1GB。不改策略，光调 memory_limit 没用，PHP 层面限制不住底层进程实际占用。
- 别信
php -d memory_limit=-1 composer install，这只是骗过 PHP 的内存检查，OOM Killer 照杀不误 - swap 不是万能的，但 512MB 机器配 1GB swap 是性价比最高的兜底手段（
dd if=/dev/zero of=/swapfile bs=1G count=1 && mkswap /swapfile && swapon /swapfile） - swap 启用后必须调低
vm.swappiness（建议设为 10），否则 PHP 进程会过早换出，反而拖慢安装速度
--no-plugins 能省多少内存？什么情况下必须加
Composer 插件（比如 hirak/prestissimo、symfony/flex）在 install 阶段会提前加载并执行钩子逻辑，每个插件都可能实例化一堆服务类。禁用后，内存峰值常能压到原来的 1/3～1/2。
- 加
--no-plugins不影响最终安装结果，只是跳过插件的“增强行为”（如自动脚本执行、包配置注入） - 如果项目没用到 Flex、Doctrine Behaviors、或自定义 installer，基本可以安全加；用了的话，得确认是否真需要它在 install 时介入
- 配合
--no-scripts更彻底（跳过post-install-cmd等），但要注意后续是否要手动补运行
还有哪些参数能一起压内存峰值
单靠一个参数不够，得组合压制：插件关掉、并发降下来、缓存少读点、解析少做点。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
--no-dev：开发依赖不解析不下载，对内存和时间都是立竿见影的节省（CI 环境必加） -
--prefer-dist：强制走压缩包而非 Git 克隆，避免临时解包+Git 对象加载的内存开销 -
-v或--verbose反而会增内存（日志对象堆积），非调试时去掉 - 如果已跑过一次，删掉
vendor/前先清空~/.composer/cache/，旧缓存有时带损坏索引，触发反复重试解析
为什么 composer update 比 install 更容易崩
update 要重新计算整个依赖图、比对版本约束、尝试回溯求解——这个过程算法复杂度高，且 Composer 会缓存中间状态对象，512MB 下大概率撑不住。而 install 只是按 composer.lock 精确还原，可控得多。
- 线上部署永远用
composer install，别用update - 如果 lock 文件缺失或过期，宁可在高配机器上生成好再传上去，也不要在 512MB 机上硬跑
update - 某些旧版 Composer（packagist.org 元数据时有内存泄漏，升级到 2.x 能缓解（但 2.x 默认内存要求更高，需同步加
--no-plugins --no-dev --prefer-dist）
swap 和 --no-plugins 是底线组合，但真正卡住的往往是某个插件或 dev 依赖偷偷拉了巨包（比如 phpstan/phpstan 或 larastan/larastan）。遇到反复 OOM，先看 composer.json 里 require-dev 有没有可疑大块头，删了再试——比调参数快得多。
