答案是php -d memory_limit=2g必须写在composer命令前，顺序错误则php收不到参数；windows powershell需加引号，ubuntu wrapper需用绝对路径；单位只认g/m，-1被v2+拒绝；composer_memory_limit仅为软限制，不绕过php底层限制。
php -d memory_limit=2G 必须写在 composer 命令前面
命令顺序错了就完全无效。写成 composer install -d memory_limit=2G，PHP 根本收不到参数，composer 会把 -d 当作子命令忽略。正确写法是：php -d memory_limit=2G composer install。
Windows PowerShell 用户还要注意：等号必须加引号，否则 - 被识别为 PowerShell 参数 —— 应写成 php -d "memory_limit=2G" composer install。
如果 which composer 返回的是 /usr/bin/composer（Ubuntu 等系统的 shell wrapper），-d 很可能被 wrapper 忽略。此时应改用绝对路径：php -d memory_limit=2G /usr/bin/composer install。
单位只认 G 或 M，2GB、2g、2.0G 都不被识别；-1 在 Composer v2+ 中会被主动拒绝运行，报错 Composer requires the memory limit to be set to a value greater than 0。
COMPOSER_MEMORY_LIMIT 是软限制，不绕过 PHP 底层限制
COMPOSER_MEMORY_LIMIT 只控制 Composer 自己的依赖求解缓存、JSON 解析预分配等内部逻辑，它不改变 PHP 进程的硬限制。进程在第 129MB 就被 kill，Composer 根本没机会读到这个变量。
验证是否生效：加 -v 参数运行，开头几行会打印 Memory limit: 2G —— 但这只是 Composer 自己“以为”能用这么多，不代表 PHP 允许。
Linux/macOS 下写法：COMPOSER_MEMORY_LIMIT=2G php -d memory_limit=2G composer install（等号前后不能有空格）；Windows CMD：set COMPOSER_MEMORY_LIMIT=2G && php -d memory_limit=2G composer install。
对 composer install 几乎无效，因为解包和软链由 PHP 直接承担；对 composer update 有轻微缓解，但 SAT 求解阶段仍卡在 PHP 底层限制上。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
为什么 composer update 比 install 更容易爆内存
composer update 要在单个 PHP 进程里跑 SAT（布尔可满足性）求解，反复尝试版本组合、回溯冲突，内存增长是指数级的；而 composer install 只按 composer.lock 精确还原，开销小得多。
日常开发优先用 composer install，不是 update；真要升级，缩小范围：composer update monolog/monolog guzzlehttp/guzzle，避免全量重算。
加 --no-plugins 关掉插件（尤其已废弃的 hirak/prestissimo），某些插件会额外加载几十个类；--no-dev 和 --optimize-autoloader 对 solver 阶段几乎没用——它们生效在 install 后期，而爆内存多发生在解析阶段。
系统级 “Killed” 不是 PHP 报错，是 OOM Killer 干的
如果终端只显示 Killed，没有 PHP 错误堆栈，说明进程被 Linux 内核的 OOM Killer 终止了，根本没走到 PHP 报错那步。
常见于 Docker 容器或低配服务器（如 1GB 内存机器）。此时调高 php -d memory_limit 可能无效，因为系统物理内存已经见底。
临时解法：添加 Swap 文件，例如创建 2GB Swap：sudo fallocate -l 2G /swapfile && sudo chmod 600 /swapfile && sudo mkswap /swapfile && sudo swapon /swapfile。
Docker 中启动时加内存限制：docker run -m 2g your_image；CI/CD 中优先用 composer install --no-dev --prefer-dist --optimize-autoloader 降低资源需求。
真正关键的点在于：你看到的报错位置（比如 Solver.php 第 223 行）说明问题出在 PHP 进程本身被 memory_limit 截断，而不是 Composer 逻辑写得差。所有“优化参数”都救不了底层限制，必须先确保 php -d memory_limit=2G 生效且作用于实际执行的 PHP 进程 —— 尤其要注意 CLI 模式下加载的是哪个 php.ini，别改错了配置文件。
