最有效解法是php -d memory_limit=2G composer install，因2G经CI验证稳妥且不触发OOM；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 - Windows CMD 可不加引号，但等号前后不能有空格
- 别用
$(which composer)，某些 shell wrapper 会丢掉-d参数
COMPOSER_MEMORY_LIMIT 环境变量只管 Composer 自己的逻辑
它控制的是依赖解析缓存、SAT 求解中间状态等内部结构大小，**不改变 PHP 底层分配能力**。设了 COMPOSER_MEMORY_LIMIT=-1 却没调高 php -d memory_limit，等于让司机盯着油表狂踩油门，油箱还是空的。
- 值必须是纯数字加单位：
2G或2147483648，不能写"2G"或2g - 对
composer update效果明显，对composer install作用有限——解包和软链由 PHP 直接承担 - CI/CD 中需显式导出，GitHub Actions 默认不透传环境变量
- 加
-v参数可验证是否生效：开头几行会打印Memory limit: 2G
为什么改 php.ini 不推荐
Composer 默认走 CLI 模式 PHP，而 CLI 和 Web（如 php-fpm）通常用不同 php.ini 文件。你改了 /etc/php/8.2/apache2/php.ini，对终端里的 composer 毫无影响。
立即学习“PHP免费学习笔记（深入）”；
- 查 CLI 实际配置：
php -i | grep "Loaded Configuration File" - 看当前生效值：
php -r "echo ini_get('memory_limit');" - 改完要重启终端或重载 shell 配置（
source ~/.zshrc） - 全局调高会影响所有 CLI 脚本，比如部署脚本、数据库迁移，风险不可控
Docker 和 CI 环境里最容易忽略的 cgroup 限制
即使你在容器里设了 php -d memory_limit=-1 和 COMPOSER_MEMORY_LIMIT=-1，宿主机的 cgroup 仍可能在进程达到内存上限时直接 kill 掉它，且不抛出 PHP 错误——只会静默退出或卡住。
- Docker 启动时加
--memory=4g显式声明上限 - Kubernetes 中检查 Pod 的
resources.limits.memory - CI 流水线（如 GitHub Actions）默认内存有限，建议固定用
php -d memory_limit=2G而非-1 - 确认没启用 xdebug：
php -d zend_extension= -d xdebug.mode=off composer install，否则内存翻倍
php -d memory_limit=2G composer install --no-dev。2G 是大量 CI 验证过的平衡点，够用、不触发 OOM Killer，也避开了 -1 在容器中被系统误判的风险。真正卡住时，先看是不是 xdebug 没关、autoload 扫描范围过大，或者锁文件损坏——这些比调内存更常是真凶。 
