优先执行php -d memory_limit=2g composer install，该命令临时提升php内存限制至2gb，仅作用于当前命令且不污染环境，是解决composer allowed memory size exhausted错误最直接有效的方案。
别碰 Swap 分区。Composer 报 Allowed memory size exhausted，根本不是内存不够，而是 PHP CLI 进程被默认的 memory_limit 卡死——调高它，问题当场消失。
php -d memory_limit=2G 是唯一该优先试的命令
这是最干净、最可控、且不污染环境的操作：参数只作用于当前命令，不改 php.ini，不影响 PHPUnit、PHPStan 或其他 CLI 工具。
- 单位必须是
G（不是GB或M），2G是 CI 环境大规模验证过的稳妥值 - 顺序不能错：
php -d memory_limit=2G composer install—— 写成composer install -d memory_limit=2G会被 Composer 当作子命令忽略 - Linux/macOS 直接执行；Windows PowerShell 用户必须加引号：
php -d "memory_limit=2G" composer install，否则-被识别为 PowerShell 参数 - 如果
which composer返回的是/usr/bin/composer（Ubuntu 等系统 wrapper），要改用绝对路径：php -d memory_limit=2G /usr/bin/composer install
COMPOSER_MEMORY_LIMIT 环境变量常被误用
这个变量只控制 Composer 自身逻辑（比如依赖求解器）的内存分配，**不绕过 PHP 底层限制**。如果 PHP 进程在 128MB 就崩溃了，这个变量根本没机会生效。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 正确配合方式：
COMPOSER_MEMORY_LIMIT=1G php -d memory_limit=2G composer update - 单位只认
M和G，1.5G不被识别，得写1536M - 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
--no-dev 和 --optimize-autoloader 能减负，但救不了 solver 阶段
依赖求解（solver）阶段发生在是否安装 dev 包之前，它要遍历所有可能的版本组合。哪怕你加了 --no-dev，只要 composer.json 里存在宽松约束（如 "monolog/monolog": "^1.0 || ^2.0"），solver 仍会爆内存。
-
--no-dev有效跳过require-dev的安装，但对 solver 峰值内存影响有限 -
--optimize-autoloader（或-o）只在install后期生成 autoload 映射时起作用，不缓解前期解析压力 - 真正能降 solver 负担的是收紧版本约束、删掉无用包、升级到 Composer 2.5+（对大仓库做了内存优化）
- Docker 环境下若用
php:alpine，注意其默认未启用ZEND_MM_ALLOC，内存管理更激进，建议换php:slim或显式设COMPOSER_MEMORY_LIMIT=-1
Swap 分区会让 Composer 更慢甚至失败
Swap 是磁盘模拟内存，而 Composer 在解析依赖或生成 autoload 映射时频繁读写文件。启用 Swap 后，I/O 成为瓶颈，命令卡在 Loading composer repositories 或直接超时失败——这不是扩容，是自缚手脚。
- 执行
dd if=/dev/zero of=/var/swap.1 bs=1M count=2048等操作，对 Composer 内存问题毫无帮助 - CI/CD 流水线（如 GitHub Actions）资源受限，Swap 更不可行；此时应固定上限（如
2G），避免容器 OOM - 某些旧资料推荐 Swap，是因为混淆了“内存不足”和“I/O 卡顿”的根因——现在明确：Composer 的瓶颈从来不在 RAM 容量，而在 PHP 进程的
memory_limit设置
真正容易被忽略的点是：你调用的到底是不是真正的 PHP 脚本？很多系统级 composer 是 shell wrapper，-d 参数根本传不进去。先 which composer，再决定用 php -d + 绝对路径，比盲目开 Swap 实在得多。
