先查真实值：运行php -r "echo ini_get('memory_limit');"和php --ini确认CLI模式下的实际memory_limit及配置路径；php -d memory_limit=2G是PHP内核级硬限制，COMPOSER_MEMORY_LIMIT=2G是Composer软提示，两者需配合使用才最稳。
直接改 php.ini 里的 memory_limit 不解决问题，除非你确认改的是 CLI 模式下真正生效的那个文件——多数人失败就卡在这一步。
怎么确认当前 Composer 用的 memory_limit 是多少
别猜，先查真实值。Composer 启动时用的是 PHP CLI SAPI，它加载的配置和 Web 服务器完全无关。
- 运行
php -r "echo ini_get('memory_limit');"，输出类似128M或-1才是真实限制 - 再跑
php --ini，重点看Loaded Configuration File这一行路径（比如/etc/php/8.2/cli/php.ini） - 如果输出是
none，说明 CLI 没加载任何php.ini，memory_limit就是编译默认值（通常 128M），这时改系统级配置无效，必须用命令行覆盖
php -d memory_limit=2G 和 COMPOSER_MEMORY_LIMIT=2G 的区别
这两个参数作用层面不同，混用容易误判效果。
-
php -d memory_limit=2G是 PHP 内核级硬限制：一旦超限，直接抛Fatal error: Allowed memory size exhausted，Composer 都没机会响应 -
COMPOSER_MEMORY_LIMIT=2G是 Composer 自己读取的软提示：它只影响内部缓存策略和部分预分配逻辑，不能绕过 PHP 底层限制 - 所以最稳组合是两者都设：
php -d memory_limit=2G COMPOSER_MEMORY_LIMIT=2G composer install - 注意单位必须大写
G，2g或2048M在某些 PHP 版本下会解析失败
为什么加了 Swap 还是被 Killed
进程被系统 Killed（不是报错）说明 OOM Killer 干掉了它，这和 PHP 的 Allowed memory size exhausted 是两回事。
立即学习“PHP免费学习笔记（深入）”；
- PHP 报错是自己主动放弃；被
Killed是 Linux 内核强制终止，连错误都没法输出 - 此时光调
memory_limit没用，得看系统可用内存+Swap 是否真够用：free -h看实际可用，swapon --show确认 Swap 已启用 - 低配 VPS（比如 1G 内存）即使开了 1G Swap，也建议加
--no-dev --no-scripts --prefer-dist减少内存压力 - 如果用 Docker，记得检查容器内存限制：
docker inspect看HostConfig.Memory，宿主机 Swap 对容器内进程不自动生效
最容易被忽略的一点：PHP CLI 的 memory_limit 设置在 Docker、CI 环境里经常被覆盖，比如 GitHub Actions 默认用 ubuntu-latest 镜像，它的 CLI php.ini 里 memory_limit 是 128M，且你无权修改——这种场景下，php -d 是唯一可靠手段。
