95%的composer内存溢出可用php -d memory_limit=2g composer install当场解决，因其在进程启动时直接覆盖php默认内存限制，仅作用于当前命令，无需修改配置、重装或重启服务。
php -d memory_limit=2G 是第一优先级操作
Composer 报 Allowed memory size exhausted，95% 以上不是物理内存真不够，而是 PHP CLI 进程被默认的 memory_limit 卡死。直接在命令前加 php -d memory_limit=2G 就能解决，不改配置、不重启、不污染环境。
常见错误现象：执行 composer install 卡在 Loading composer repositories 或崩溃在 Solver.php 第 223 行——这说明依赖求解器（solver）正在吃内存，但 PHP 进程早在它发力前就被掐断了。
- 单位必须是
G（不是GB或M），2G是 CI 环境大规模验证过的安全值 - 顺序不能错：
php -d memory_limit=2G composer install；写成composer install -d memory_limit=2G会被忽略 - Linux/macOS 直接运行；Windows PowerShell 必须加引号：
php -d "memory_limit=2G" composer install - 如果
which composer返回/usr/bin/composer（Ubuntu wrapper），得用绝对路径：php -d memory_limit=2G /usr/bin/composer install
Swap 分区不是 Composer 内存问题的正解
看到报错里有 lack of memory or swap 就去配 Swap，是典型归因错误。Swap 是磁盘虚拟内存，Composer 的瓶颈在 PHP 进程内存分配上限，不是系统物理内存不足。加 Swap 反而会因 I/O 拖慢整个安装流程，尤其在 SSD 性能受限或 HDD 机器上更明显。
只有当你确认以下两点同时成立时，才考虑 Swap：
-
free -m显示可用内存长期低于 512MB，且php -d memory_limit=2G已生效但仍被系统Killed - 你无法修改 PHP 配置、也无法控制运行环境（如某些老旧共享主机）
若真要配，用 2GB Swap 文件最稳妥：
sudo dd if=/dev/zero of=/var/swap.1 bs=1M count=2048 sudo mkswap /var/swap.1 sudo swapon /var/swap.1
注意：swapon 后需手动加到 /etc/fstab 才能永久生效，否则重启即丢。
COMPOSER_MEMORY_LIMIT 环境变量常被误用
这个变量只控制 Composer 自身逻辑（比如依赖求解器内部缓存），**完全不绕过 PHP 的 memory_limit 底层限制**。如果 PHP 进程在 128MB 就被 kill，Composer 根本没机会读到这个变量。
它真正起效的场景极少，仅限于 Composer 主动报 Not enough memory, need XXX more 这类提示时。日常 install 基本无效，update 也只轻微缓解。
- 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 - 永远配合
php -d memory_limit=2G使用，单独设它没用
为什么 --no-dev 和 --prefer-dist 救不了 solver 阶段
--no-dev 跳过 require-dev 安装，但依赖求解（solver）发生在是否安装 dev 包之前。只要 composer.json 里有宽松约束（如 "monolog/monolog": "^1.0 || ^2.0"），solver 就要遍历所有组合，内存峰值照爆。
--prefer-dist 只影响下载方式（zip vs git clone），对 solver 阶段零影响；--optimize-autoloader 更晚，在 autoload 生成阶段才起作用。
- 真正降 solver 内存的方法：收紧版本约束（把
^1.0改成^1.25）、删掉不用的require-dev条目（哪怕不装，它们仍参与图构建） - 用
composer why-not vendor/package:version定位拖慢 solver 的包 - Docker 环境下若用
php:alpine，注意其默认未启用ZEND_MM_ALLOC，内存管理更激进，建议换php:slim或显式设COMPOSER_MEMORY_LIMIT=-1
最易被忽略的一点：Composer 的内存问题几乎全集中在 update 阶段，因为它是 SAT 求解，指数级复杂；install 只是按 composer.lock 还原，开销小得多。别一出问题就猛加内存，先看清楚你跑的是哪个命令。
