必须先试php -d memory_limit=2g composer install，因它是唯一硬控php进程内存的解法；composer_memory_limit仅为软限制，不绕过php底层限制，且对install几乎无效。
直接调高 PHP 的 memory_limit 是唯一必须先试的解法，其他操作都是次要或无效的。
php -d memory_limit=2G 必须写在 composer 命令前面
顺序错就完全失效：写成 composer install -d memory_limit=2G 会被 Composer 当作子命令忽略，PHP 根本没收到参数。
- 正确写法：
php -d memory_limit=2G composer install - Windows PowerShell 用户必须加引号：
php -d "memory_limit=2G" composer install，否则-被识别为 PowerShell 参数 - 如果
which composer返回/usr/bin/composer（Ubuntu 等系统的 shell wrapper），-d 参数大概率被忽略——应改用绝对路径：php -d memory_limit=2G /usr/bin/composer install - 单位只认
G或M，2GB、2g、2.0G都不被识别
COMPOSER_MEMORY_LIMIT 环境变量作用非常有限
它只控制 Composer 自身逻辑（比如依赖求解缓存大小），**不绕过 PHP 底层的 memory_limit 限制**。进程在第 129MB 就被 kill，Composer 根本没机会读到这个变量。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- Linux/macOS 写法：
COMPOSER_MEMORY_LIMIT=2G composer install（等号前后不能有空格） - Windows CMD：
set COMPOSER_MEMORY_LIMIT=2G && composer install - PowerShell：
$env:COMPOSER_MEMORY_LIMIT="2G"; composer install - 对
composer install几乎无效——解包和软链由 PHP 直接承担；对composer update有轻微缓解，但 solver 阶段仍受 PHP 底层限制卡死
为什么 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 后期，而爆内存多发生在解析阶段
真正关键的点在于：你看到的报错位置（比如 Solver.php 第 223 行）说明问题出在 PHP 进程本身被 memory_limit 截断，而不是 Composer 逻辑写得差。所有“优化参数”都救不了底层限制，必须先确保 php -d memory_limit=2G 生效且作用于实际执行的 PHP 进程。
