php -d memory_limit=-1 并非万能，需先区分是php进程崩溃还是composer假死；常见因调用wrapper、powershell未加引号、ci禁用-1等导致失效，应改用绝对路径、设环境变量或降级为2g。

直接加 php -d memory_limit=-1 composer install 能快速绕过报错，但不是所有场景都适用——关键得先分清是 PHP 进程真崩了，还是 Composer 自己在“装死”。

为什么 php -d memory_limit=-1 有时没用

常见错误现象：明明加了 -d 参数，还是报 Allowed memory size exhausted，甚至卡在 Loading composer repositories 阶段。

• 你调用的 composer 命令可能根本不是 PHP 脚本，而是系统级 wrapper（比如 Ubuntu 用 apt install composer 装的），-d 参数被忽略
• 验证方式：which composer；如果输出是 /usr/bin/composer，大概率是 wrapper，得改用 php -d memory_limit=-1 /usr/bin/composer install 或直接下载 composer.phar
• PowerShell 用户必须加引号：php -d "memory_limit=-1" composer install，否则 -1 被当成 PowerShell 参数解析
• CI 环境（如 GitHub Actions）常禁用 -1，换 2G 更稳：php -d memory_limit=2G composer install

COMPOSER_MEMORY_LIMIT 环境变量到底管不管用

它只控制 Composer 自身逻辑（比如依赖求解），不绕过 PHP 底层内存限制。也就是说：PHP 进程在第 129MB 就被 kill 了，Composer 根本没机会读到这个变量。

Workflow Decomposer

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

下载

• 有效写法（Linux/macOS）：COMPOSER_MEMORY_LIMIT=-1 composer install（等号不能有空格）
• Windows CMD：set COMPOSER_MEMORY_LIMIT=-1 && composer install
• PowerShell：$env:COMPOSER_MEMORY_LIMIT="-1"; composer install
• 对 composer update 效果明显，对 install 作用有限——因为 install 主要开销在解压和软链，由 PHP 直接承担

不靠硬提内存，还能怎么减负

很多项目爆内存不是因为包多，而是流程没剪干净。尤其在 CI/CD 或 Docker 环境里，盲目加内存反而掩盖真实问题。

• 加 --no-dev：跳过 require-dev 包，CI 构建或线上部署必加
• 用 --prefer-dist（默认开启）：强制走 zip 包而非 git clone，避免 git 操作吃内存
• 删掉 vendor 和 composer.lock 后重试：锁文件损坏或版本冲突会引发异常内存占用
• 升级 Composer：composer self-update，2.x 比 1.x 内存管理更优
• Docker 环境下注意：Alpine 镜像默认没开 ZEND_MM_ALLOC，内存管理更激进，建议换 php:slim 或显式加 export COMPOSER_MEMORY_LIMIT=-1

composer install 和 composer update 的内存行为差异

install 读 composer.lock，理论上内存占用低；update 要重新跑 SAT 算法，遍历所有版本约束，是内存杀手。但现实常相反——因为 lock 文件过大（比如含 dev-master 提交哈希、完整 package-versions 映射），install 反而更吃内存。

• 检查 composer.lock 大小：超过 5MB 就该警惕，可能是 require-dev 过度或用了太多 "minimum-stability": "dev"
• composer create-project 卡在 Loading composer repositories…？这个阶段涉及大量 JSON 解析和对象构建，比普通 install 更吃内存，可加 --no-plugins --no-scripts
• CI 流水线里别依赖 -1，固定设为 1.5G 或 2G 更稳妥，避免某次异常依赖爆炸拖垮整个构建节点

真正容易被忽略的是：你看到的内存报错，往往不是 PHP 真不够用，而是 Composer 在解析一个膨胀的、嵌套过深的、混杂大量 dev 依赖的锁文件时，把所有元数据一股脑全塞进内存——这时候调高上限只是延缓崩溃，而不是解决问题本身。