最有效解法是php -d memory_limit=2g composer update，必须php前置、-d参数不漏、等号无空格；-1在ci或容器中易触发oom，composer_memory_limit更适配ci/cd，dump-autoload内存不足多因扫描非代码目录所致。
直接加内存参数最有效，但必须用对方式、设对值，否则白忙活
php -d memory_limit=2G 是最稳的临时解法
composer update 吃内存是因为要重算整个依赖图、下载元数据、跑 SAT 求解器，峰值常超 1.5GB。默认 128M 或 256M 根本不够。
- 命令必须写成
php -d memory_limit=2G composer update，php在最前，-d参数不能漏，等号两边不能有空格 - 别用
-1（无限制）：CI 环境可能拦截，容器里还可能触发 OOM killer 杀进程 - 如果用的是
composer.phar，同样要写成php -d memory_limit=2G ./composer.phar update，只写./composer.phar会绕过-d - Windows PowerShell 中
-1要加引号：php -d "memory_limit=-1" composer update
COMPOSER_MEMORY_LIMIT 环境变量更适合 CI/CD
这个变量是 Composer 原生支持的，只影响它自己的依赖解析逻辑，比全局 memory_limit 更精准。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- Linux/macOS 临时生效：
export COMPOSER_MEMORY_LIMIT=2G，然后运行composer update - GitLab CI 示例：
php -d memory_limit=2G /usr/bin/composer update --no-interaction（注意显式调用php） - GitHub Actions 中若用
composer/setup-phpAction，直接加memory-limit: 2G输入项即可 - 别在
.env或phpunit.xml里设PHP_MEMORY_LIMIT——Composer 不读这些
为什么 dump-autoload 也报内存不足
这不是 autoload 本身的问题，而是它被迫扫描了不该扫的目录，比如 logs/、storage/、node_modules/，或者 composer.json 的 autoload 配置误包含了 dist/。
- 运行
composer dump-autoload --no-scripts单独测试，排除脚本干扰 - 检查
composer.json里的autoload和autoload-dev，确认没把非 PHP 目录包含进去 - 删掉根目录下误放的
logs/、storage/app/这类大体积非代码文件 - 如果项目用了 Laravel，
storage/和bootstrap/cache/通常不该在 autoload 范围内
别碰 php.ini，除非你清楚 CLI 和 Web 的配置是两套
改 php.ini 容易白改：Web 服务器（如 PHP-FPM）和 CLI 模式加载的不是同一个配置文件。
- 先查 CLI 实际加载路径：
php --ini，看 “Loaded Configuration File” 行 - 验证是否生效：
php -r "echo ini_get('memory_limit');"，输出应为2147483648或2G - Docker 或 CI 环境不建议走这条路，
-d参数更可靠 - 改完
php.ini不用重启 Nginx/Apache，但得新开终端或source ~/.zshrc
真正容易被忽略的是：即使加了内存，composer update 仍可能静默失败——比如被系统 OOM killer 杀掉，或因 xdebug 开着导致内存翻倍。遇到卡住无输出，先关 xdebug，再试 --dry-run 看变化范围，别直接硬上。
