Composer 本身不提供内存限制功能，真正起作用的是 PHP 的 memory_limit 或 COMPOSER_MEMORY_LIMIT 环境变量；后者仅为软上限，且仅影响依赖解析等部分行为，而解压、autoload 生成等仍由 PHP 内存限制控制。
Composer 本身不提供内存限制功能，它只响应外部传入的内存上限；真正能设上限的是 PHP 解释器或 COMPOSER_MEMORY_LIMIT 环境变量——但后者只是软刹车，不能绕过 PHP 底层的 memory_limit。
为什么 composer config memory-limit 不生效
这是最常见的误操作。Composer 的 config 子命令根本不支持 memory-limit 这个键，所有类似 composer config --global memory-limit -1 的写法都会静默失败。官方明确不支持在 composer.json 中配置该参数，也不会读取 "config": {"memory-limit": "-1"} 这类字段。
-
composer config只管理自身配置项（如cache-dir、github-protocols），memory-limit不在其白名单中 - 试图用
composer.json配置会直接被忽略，连警告都不会输出 - 网上教程中大量出现该错误写法，根源是混淆了 Composer 自身逻辑与 PHP 运行环境的边界
COMPOSER_MEMORY_LIMIT 怎么设才真正起作用
这个环境变量由 Composer 主动读取，用于控制其内部依赖解析循环、缓存预估等行为的软上限，但它不改变 PHP 的 memory_limit。值必须合法且前置执行：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 正确写法只有两种形式：
-1（不限制）或纯数字字节（如2147483648），不能带单位，也不能加引号："-1"、2G、2048M全部无效 - Linux/macOS：直接前置，
COMPOSER_MEMORY_LIMIT=2147483648 composer install - Windows CMD：
set COMPOSER_MEMORY_LIMIT=2147483648 && composer install - PowerShell：
$env:COMPOSER_MEMORY_LIMIT="2147483648"; composer install（注意这里引号仅包裹值，不是语法必需，但 PowerShell 要求字符串赋值必须引号） -
COMPOSER_MEMORY_LIMIT=0表示回退到php.ini的memory_limit，不是“禁用”
php -d memory_limit 才是硬限制，顺序和路径都不能错
这是唯一能真正防止 Allowed memory size exhausted 的方式，它在 PHP 进程启动前就强制设定内存上限，绕过所有配置干扰。但极易因调用方式出错而失效：
- 必须写成
php -d memory_limit=-1 /path/to/composer.phar install，不能用$(which composer)—— shell wrapper 会吞掉-d参数 - Windows 下若用
composer.bat封装，应改用php -d memory_limit=-1 composer.phar install，避免批处理脚本干扰 - PowerShell 中需加引号分隔参数：
php "-d" "memory_limit=-1" composer.phar install -
php -d memory_limit=-1优先级高于COMPOSER_MEMORY_LIMIT，一旦设置，后者会被忽略 - 某些 Composer v2.5+ 版本在检测到
memory_limit=-1时会主动退出并报Composer requires the memory limit to be set to a value greater than 0，此时只能退回到COMPOSER_MEMORY_LIMIT=-1+ 提高php -d memory_limit=2G
真·爆内存时，别只盯着内存数字
很多项目调高到 2G 甚至 4G 仍报错，说明问题不在容量，而在流程本身：
- 启用
xdebug会让内存占用翻倍以上，CI 或部署时务必关掉：php -d zend_extension= -d xdebug.mode=off composer install -
"psr-4": {"": "src/"}这类宽泛 autoload 规则会扫描整个vendor目录，生成巨大 classmap - 旧版 Composer（1.x）或低版本 PHP（如 7.4）存在解析逻辑缺陷，导致反复重试依赖图计算
- Docker 容器里即使设了
COMPOSER_MEMORY_LIMIT=-1，宿主机 cgroup 的memory.limit_in_bytes仍可能触发 OOM killer
最常被忽略的一点：Composer 的 COMPOSER_MEMORY_LIMIT 对 install 阶段的解压、autoload 生成等操作基本无效——这些由 PHP 直接承担，只受 php -d memory_limit 控制。
