正确写法是php -d memory_limit=2G composer install，该命令将PHP内存限制提至2GB且仅作用于当前命令，顺序必须为php -d在前、composer在后；COMPOSER_MEMORY_LIMIT仅控制Composer内部逻辑，不绕过PHP底层限制。
php -d memory_limit 必须写在 composer 命令前面
这条命令不是 Composer 的参数，而是 PHP 解释器的启动选项。顺序错就完全失效：写成 composer install -d memory_limit=2G 会被当作子命令忽略，PHP 根本没收到参数。
正确写法只有这一种：php -d memory_limit=2G composer install。
如果用的是 composer.phar，必须写全路径：php -d memory_limit=2G /path/to/composer.phar install。
Linux/macOS 直接运行即可；Windows PowerShell 必须加引号：php "-d" "memory_limit=2G" composer install；CMD 可不加引号，但等号前后不能有空格。
别用 $(which composer)——某些 shell wrapper（如 Ubuntu 的 /usr/bin/composer）会丢掉 -d 参数。
COMPOSER_MEMORY_LIMIT 环境变量只影响 Composer 内部逻辑
它控制的是依赖求解缓存、SAT 回溯步数等内部结构大小，不绕过 PHP 底层的 memory_limit 限制。设了 COMPOSER_MEMORY_LIMIT=-1 却没调高 php -d memory_limit，等于让司机盯着油表狂踩油门，油箱还是空的。
单位只认纯数字或大写 G/M（如 2G、2147483648），"2G"、2g、2GB 都无效。
对 composer install 几乎无效——解包、软链由 PHP 直接承担；对 composer update 有轻微缓解，但 solver 阶段仍受 PHP 底层限制卡死。
CI/CD 中建议组合使用：php -d memory_limit=1.5G COMPOSER_MEMORY_LIMIT=1536M composer install。
确认并修改 CLI 模式真正生效的 php.ini
很多人改了 /etc/php/8.2/apache2/php.ini 却发现 composer install 还是报错，根本原因是 Composer 用的是 PHP CLI 模式，和 Web 服务完全不共用配置文件。
必须先运行 php --ini 查清 Loaded Configuration File 行，比如 /etc/php/8.2/cli/php.ini；若显示 (none)，说明 CLI 根本没加载任何配置，此时 memory_limit 是编译默认值（通常 128M）。
编辑对应文件，把 memory_limit = 128M 改为 memory_limit = 2G（不要加引号，单位必须大写，禁用 Xdebug）。
改完要新开终端或执行 source ~/.zshrc 刷新环境；Docker 容器内改完需重建容器，docker exec 进去改无效。
为什么有时调高内存也没用？真凶往往不是内存
看到 OOM 就加内存，容易忽略真正拖垮 Composer 的行为：
启用了 xdebug：会让内存占用翻倍以上，临时禁用更有效：php -d zend_extension= -d xdebug.mode=off composer install；composer.lock 损坏或 vendor 残留，先清掉再试：rm -rf vendor composer.lock && composer clear-cache；
旧版 Composer（1.x）或低版本 PHP（如 7.4 + Composer 2.5+）存在兼容问题，导致依赖解析反复重试；
Docker 容器里没同步 cgroup 限制：即使设了 COMPOSER_MEMORY_LIMIT=-1，宿主机 cgroup 仍可能 kill 掉进程；
循环依赖或宽泛 autoload 规则（如 "psr-4": {"": "src/"}）扫描了整个 vendor 目录。
立即学习“PHP免费学习笔记（深入）”；
