优先用 php -d memory_limit=2G 临时扩容，而非启用 Swap；因 Composer 依赖解析时 I/O 拖累远超内存不足，2G 是 CI 验证的稳妥值，且仅作用于当前命令不污染环境。
直接结论：别碰Swap分区，优先用 php -d memory_limit=2G 临时扩容
Swap 是磁盘模拟内存，Composer 在解析依赖或生成 autoload 映射时频繁读写，启用 Swap 反而让命令卡死甚至失败——这不是内存不够，是 I/O 拖垮了整个流程。真正该动的是 PHP CLI 进程的内存上限，而且必须只作用于当前命令。
为什么 php -d memory_limit=2G composer install 是首选
这是最干净、最可控、且不污染环境的方式：
-
php -d参数只影响本次执行，不会改php.ini，避免影响 PHPUnit、PHPStan 或其他 CLI 工具 - 单位必须是
G（不是GB或M），2G是经过大量 CI 场景验证的稳妥值；-1在 GitHub Actions/GitLab CI 中可能被拒绝，不建议上线流程使用 - 顺序不能错：必须
php -d ...开头，如果写成composer install -d memory_limit=2G，参数会被 Composer 当作子命令忽略 - Windows PowerShell 用户需加引号：
php -d "memory_limit=-1"，否则-被识别为命令选项
COMPOSER_MEMORY_LIMIT 环境变量怎么设才生效
这个变量是 Composer 原生支持的，优先级高于 php.ini，但很多人设错位置或单位：
立即学习“PHP免费学习笔记（深入）”；
- Linux/macOS：直接前置，例如
COMPOSER_MEMORY_LIMIT=2G composer update - Windows CMD：
set COMPOSER_MEMORY_LIMIT=2G && composer install - Windows PowerShell：
$env:COMPOSER_MEMORY_LIMIT="2G"; composer install - 单位只认
M和G，写2048M会失效；1.5G不被识别，得写1536M - 它控制的是 Composer 自身内存分配逻辑，不是 PHP 底层限制——所以仍要确保 PHP CLI 的
memory_limit不低于该值，否则提前报错
哪些操作看似有用，实则掩盖真问题
以下做法短期能跑通，但长期会让项目越来越难维护：
- 盲目改系统级
php.ini的memory_limit = -1：CI 环境、Docker 容器、共享主机通常不允许，且一旦漏掉某台机器，部署就断 - 在
.env或phpunit.xml里设PHP_MEMORY_LIMIT：Composer 根本不读这些文件，纯属白忙 - 删
vendor/+composer.lock后重装：lock 文件若已损坏或含 dev-master 引用，反而触发更复杂的 SAT 求解，内存峰值更高 - 依赖
--no-dev或--prefer-dist就以为万事大吉：它们确实降低开销，但解决不了 autoload 阶段扫描logs/、storage/下巨型 JSON 文件的问题
真正该查的是：你的 composer.json 里 autoload 是否误包含了 node_modules/？vendor/ 外有没有未清理的测试数据目录？composer.lock 文件是否超过 5MB？这些才是内存耗尽背后的真实推手。
