Composer提示由于内存限制导致进程死亡_优化PHP-CLI的配置【服务器优化】

先查真实值：运行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 的命令行接口，它加载的配置和 Web 服务器用的那套完全是两码事。

• 先运行 php -r "echo ini_get('memory_limit');"，输出的结果（比如 128M 或 -1）才是当前 CLI 环境下的真实内存限制。
• 接着执行 php --ini，重点关注 Loaded Configuration File 这一行显示的路径（例如 /etc/php/8.2/cli/php.ini）。
• 如果这里显示的是 none，那就意味着 CLI 模式没有加载任何 php.ini 文件，此时的 memory_limit 就是 PHP 编译时的默认值（通常是 128M）。在这种情况下，修改系统级的配置文件是无效的，必须通过命令行参数来覆盖。

php -d memory_limit=2G 和 COMPOSER_MEMORY_LIMIT=2G 的区别

这两个参数虽然看起来目标一致，但作用层面完全不同，混为一谈很容易导致误判。

• php -d memory_limit=2G 是作用于 PHP 内核的硬性限制：一旦脚本内存消耗超过这个值，PHP 会直接抛出 Fatal error: Allowed memory size exhausted 错误，Composer 自身都来不及做出反应。
• COMPOSER_MEMORY_LIMIT=2G 则是 Composer 工具自己读取的一个软性提示：它主要影响 Composer 内部的缓存策略和部分内存预分配逻辑，但无法绕过 PHP 底层设定的内存上限。
• 所以，最稳妥的组合是两者同时设置：php -d memory_limit=2G COMPOSER_MEMORY_LIMIT=2G composer install。
• 另外有个细节需要注意：单位必须使用大写的 G，写成 2g 或 2048M 在某些 PHP 版本中可能会导致解析失败。

为什么加了 Swap 还是被 Killed

如果进程是被系统直接 Killed（而不是抛出 PHP 错误），这说明它被 Linux 的 OOM Killer 机制强制终止了。这和我们前面讨论的 PHP 内存报错，完全是两回事。

立即学习“PHP免费学习笔记（深入）”；

• PHP 报错是脚本主动放弃执行；而被 Killed 则是 Linux 内核的强制干预，进程连输出错误信息的机会都没有。
• 到了这一步，仅仅调整 memory_limit 已经没用了。你得检查系统的实际可用内存和 Swap 是否真的充足：用 free -h 查看可用资源，用 swapon --show 确认 Swap 分区确实已经启用。
• 对于低配置的 VPS（例如只有 1G 内存），即便开启了 1G 的 Swap，也建议在执行 Composer 时加上 --no-dev --no-scripts --prefer-dist 这些参数，以显著减少内存压力。
• 如果是在 Docker 环境中运行，别忘了检查容器的内存限制：通过 docker inspect 查看 HostConfig.Memory 设置，要知道，宿主机的 Swap 空间并不会自动对容器内的进程生效。

还有一个最容易被忽略的场景：在 Docker 或 CI/CD（如 GitHub Actions）环境中，PHP CLI 的 memory_limit 设置经常被镜像预设值覆盖。比如 GitHub Actions 默认的 ubuntu-latest 镜像，其 CLI 的 php.ini 里 memory_limit 就是 128M，而且你没有权限去修改这个镜像文件——在这种场景下，使用 php -d 参数就成了唯一可靠的手段。