Composer install 内存爆掉是因自身检查误判及 autoload 生成、脚本执行、PHP 无 opcache 等导致；应设 COMPOSER_MEMORY_LIMIT=-1、用 --no-autoloader --no-scripts、启用 opcache.enable_cli=1、加 --prefer-dist。
composer install 内存爆掉直接退出？先关掉内存检查
Composer 默认会检测可用内存，但这个检测在低配服务器（比如 512MB RAM 的 VPS）上经常误判，还没开始装包就报 Allowed memory size exhausted。它不是真没内存，而是 PHP 的 memory_limit 被 Composer 自己的检查逻辑提前卡死了。
实操建议：
- 运行前加
COMPOSER_MEMORY_LIMIT=-1环境变量，彻底绕过它的内存限制检查 - 同时确保 PHP 配置里
memory_limit不是-1（太危险），设成512M或768M更稳妥 - 别用
php -d memory_limit=-1 composer.phar install—— 这会让 PHP 完全不限制内存，容易 OOM kill 进程
vendor 目录太大、解压慢？跳过 autoload 生成和脚本执行
低内存机器最卡的不是下载，是 install 后自动跑 autoload dump 和各种 post-install-cmd 脚本。这些操作吃内存又没实际必要（尤其你只是部署静态依赖）。
实操建议：
- 用
composer install --no-autoloader --no-scripts先把包拉下来、解压完 - 等安装完成，再单独跑
composer dump-autoload --optimize（注意加--optimize，它生成的autoload_classmap.php比默认快且省内存） - 如果项目不依赖
post-install-cmd（比如不要生成配置、不编译前端资源），就永远别开--scripts
PHP 7.4+ 下 still OOM？检查 opcache.enable_cli 是否开启
PHP CLI 模式默认关闭 opcache，而 Composer 在解析大量 composer.json 和类文件时反复编译 PHP 代码，内存碎片+重复编译=雪崩。这不是 Composer 的锅，是 PHP 自身机制。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
实操建议：
- 临时启用：运行前加
php -d opcache.enable_cli=1 composer.phar install - 永久生效：在
php.ini里加一行opcache.enable_cli = 1（仅限 CLI，不影响 Web 服务） - 别开
opcache.memory_consumption太大（如 >128M），CLI 场景 64M 足够，开太大反而抢走 Composer 可用内存
实在装不上？换成 --prefer-dist + 关闭 git clone
有些包在 require 里没指定 "type": "zip"，Composer 就默认走 git clone，哪怕有 zip 包也忽略。git 过程要起子进程、解包、检出，比直接下 zip 多占 2–3 倍内存。
实操建议：
- 强制走压缩包：加
--prefer-dist参数（composer install --prefer-dist --no-autoloader --no-scripts） - 禁用 git：在
composer.json顶层加"preferred-install": {"*": "dist"}，或全局配置composer config -g preferred-install dist - 确认效果：看输出里是否出现
Downloading .../xxx.zip，而不是Cloning ...
低内存环境里，composer install 不是“能不能跑”的问题，是“怎么避开它自己设的路障”的问题。真正吃内存的从来不是下载，而是 autoload 生成、脚本执行、反复编译——这些全是可以关掉或延后的东西。别信“升级服务器”这种答案，先动参数。
