php -d memory_limit=-1有时不生效，因未作用于真正运行composer的php进程：漏写php前缀、cli与fpm php.ini路径不一致、powershell缺引号、ci禁用-d参数等；需配合composer_memory_limit及--no-dev等裁剪策略。
直接加 php -d memory_limit 参数最可靠，但必须确保它作用在真正跑 Composer 的那个 PHP 进程上——否则改了等于没改。
为什么 php -d memory_limit=-1 有时不生效
不是命令写错了，而是环境绕过了它：
- 你运行的是
./composer.phar，却漏了php前缀，系统实际调用的是默认 PHP（可能仍是 128M） -
which php和php --ini输出的Loaded Configuration File路径不一致——你改的可能是 FPM 的php.ini，CLI 根本不读 - Windows PowerShell 下没加引号：
php -d "memory_limit=-1"缺失双引号会导致参数被截断 - CI 环境（如 GitLab Runner）明确禁用
-d参数，此时必须靠COMPOSER_MEMORY_LIMIT=-1配合php -d兜底
composer install 和 composer update 的内存差异在哪
名字有误导性：composer update 是标准内存杀手，必须重跑 SAT 依赖求解、下载全部元数据、校验版本约束；composer install 理论上轻量，但前提是 composer.lock “干净”——若该文件体积超 5MB（常见于含大量 dev-master 哈希、废弃包残留），解析反而更耗内存。
删掉 vendor/ 和 composer.lock 后直接 composer update，等于强制全量重算 + 下载 + 解压，是内存峰值最高的操作组合。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
真正有效的参数组合（ThinkPHP / Laravel / CI 场景通用）
别只堆内存，要配合裁剪逻辑：
-
--no-dev：跳过require-dev中所有包（如phpunit、phpstan），内存常降 40%~60% -
--no-plugins：禁用钩子型插件，避免每个包安装后触发额外逻辑 -
--no-scripts：跳过post-install-cmd等脚本执行，防止执行未知代码放大内存压力 -
--optimize-autoloader（或-o）：生成扁平classmap，降低dump-autoload阶段内存峰值
推荐组合：php -d memory_limit=2G composer install --no-dev --no-plugins --no-scripts -o
CI/CD 中容易被忽略的底层限制
COMPOSER_MEMORY_LIMIT=2G 只影响 Composer 自身预分配逻辑，不能突破 PHP 底层限制。光设这个变量没用：
- 必须前置
php -d memory_limit=1.5G（别用-1，防止单次异常拖垮构建节点） - 确保
composer.lock已提交且未被 CI 缓存污染，否则install会悄悄退化为update - Docker 场景下，还要检查容器内存是否充足（如
docker run --memory=4g），否则即使 PHP 无限制也会被 OOM killer 杀掉
复杂点在于：内存问题往往不是单一配置能解决的，而是 CLI PHP 配置、Composer 自身变量、插件行为、lock 文件状态、容器资源四层叠加的结果。漏掉任何一层，都可能让前面所有调整失效。
