必须将 php -d memory_limit=2G 写在 composer 命令前面，如 php -d memory_limit=2G composer install；顺序错误、单位不规范（只认 G/M）、使用 COMPOSER_MEMORY_LIMIT 代替 PHP 限制均无效，且 -1 不被 Composer v2+ 允许。
php -d memory_limit 必须写在 composer 命令前面
报 Allowed memory size exhausted 时，最常见错误是把 -d 参数塞到 composer install 后面，比如 composer install -d memory_limit=2G。这完全无效——Composer 不认识这个参数，PHP 根本没收到指令。
真正生效的写法只有一种：php -d memory_limit=2G composer install。顺序错一毫秒就白忙活。
- Linux/macOS 直接运行即可
- Windows PowerShell 必须加引号：
php -d "memory_limit=2G" composer install，否则-被当命令参数解析 - 如果
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_MEMORY_LIMIT 环境变量常被误认为能“放开内存”，但它只控制 Composer 自身逻辑里的缓存大小（比如依赖求解器内部预分配），**完全不绕过 PHP 的 memory_limit 底层限制**。进程在第 129MB 就被 kill，Composer 根本没机会读到这个变量。
它对 composer update 有轻微缓解作用（因 solver 阶段会用到缓存），但对 composer install 几乎无效——解压、软链这些操作由 PHP 直接承担，不受该变量影响。
- Linux/macOS 写法：
COMPOSER_MEMORY_LIMIT=2G composer install（等号前后不能有空格） - Windows CMD：
set COMPOSER_MEMORY_LIMIT=2G && composer install - 验证是否生效：加
-v运行，开头几行会打印Memory limit: 2G
composer update 比 install 更容易爆内存
composer update 要在单个 PHP 进程里跑 SAT（布尔可满足性）求解，反复尝试版本组合、回溯冲突，内存增长是指数级的；而 composer install 只按 composer.lock 精确还原，开销小得多。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
日常开发优先用 composer install，不是 update。真要升级，务必缩小范围：
-
composer update monolog/monolog guzzlehttp/guzzle—— 避免全量重算 -
--no-plugins关掉插件（尤其已废弃的hirak/prestissimo） -
php -d zend_extension= -d xdebug.mode=off composer update—— Xdebug 会让内存占用翻倍 -
--no-dev和--optimize-autoloader对 solver 阶段几乎没用，它们生效在 install 后期
别盲目设 memory_limit=-1
设成 -1 表示无限制，但在 CI 或容器环境里容易触发 OOM Killer 杀死进程；2G 是经过大量流水线验证的平衡值：够用、兼容旧版 PHP、不会被系统误判为失控进程。
更关键的是，Composer v2+ 启动后会主动拒绝 memory_limit=-1，直接报错：Composer requires the memory limit to be set to a value greater than 0。这不是 bug，是它的安全策略。
真正能绕过这个检查的，是 COMPOSER_MEMORY_LIMIT 环境变量——但它仍需配合足够大的 php -d memory_limit 才有效。
复杂点在于：你看到的报错位置（比如 Solver.php 第 223 行）说明问题出在 PHP 进程本身被 memory_limit 截断，而不是 Composer 逻辑写得差。所有“优化参数”都救不了底层限制，必须先确保 php -d memory_limit=2G 生效且作用于实际执行的 PHP 进程。
