优化内存消耗：调整Composer运行参数适配低配服务器部署-composer-PHP中文网

composer在512mb vps上被oom kill主因是依赖图重建阶段内存峰值超800mb，需组合使用php -d memory_limit=384m、--no-dev、--no-autoloader、--prefer-dist四措施，并禁用插件、清缓存、分步执行autoload优化。

优化内存消耗：调整composer运行参数适配低配服务器部署

不是PHP没内存，是Composer在依赖图重建阶段就吃掉800MB+——它默认加载全部vendor/元数据做diff，而低配服务器根本扛不住这个对象膨胀。尤其当vendor/已存在但composer.lock有变更时，这个阶段必爆。

常见现象：命令无报错、无输出，直接退出；dmesg | tail能看到Out of memory: Kill process xxx (php)。

别信Allowed memory size exhausted错误——那说明PHP还活着；静默退出=系统OOM killer已动手
COMPOSER_MEMORY_LIMIT=-1对install基本无效，它只约束Composer自身逻辑，不管解压和symlink这些PHP底层操作
PHP CLI的memory_limit才是真上限，且必须用php -d显式传参，否则Composer可能读取到web用的php.ini（值常为128M）

单靠调内存只是拖延时间，真正稳住的关键是砍掉非必要流程。这三个参数不占额外内存，但能降低峰值30%以上：

实操命令：php -d memory_limit=384M composer install --no-dev --no-autoloader --prefer-dist

注意：不要加--optimize-autoloader在这一步——它会在install阶段触发classmap全量扫描，反而推高内存峰值。

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

很多人把--optimize-autoloader塞进install命令里，结果卡死。正确做法是先让包落地，再单独跑autoload优化：

安装完立刻执行：composer dump-autoload --optimize --classmap-authoritative
--classmap-authoritative要求所有类都在classmap中，适合无files autoload或动态加载的项目；若用了files类型，去掉这个flag，否则运行时报Class not found
如果项目启用了opcache，加php -d opcache.enable_cli=1再跑dump，能减少重复编译导致的内存碎片

验证是否生效：grep -c "classmap" vendor/autoload.php应返回非零值；php -r "var_dump(class_exists('SomeClass'));"应秒回true。

Composer的增量install会加载旧vendor/里的composer.json和installed.json做版本比对，而clean install只读composer.lock，路径更线性、临时对象生命周期更短。

操作顺序必须是：rm -rf vendor/ && composer clear-cache && php -d memory_limit=384M composer install --no-dev --no-autoloader --prefer-dist
别漏composer clear-cache——旧缓存（尤其含大量zip元数据）会拖慢解析并增加内存驻留
禁用插件：composer install --no-plugins，某些插件（如旧版hirak/prestissimo）在低内存下会因并发下载引发竞争或缓存膨胀

真正容易被忽略的是：所有参数必须同时生效。漏掉--no-dev或--no-autoloader中的任意一个，都可能导致内存峰值突破临界点——不是“差不多能跑”，而是“差一点就OOM”。