低配服务器php内存爆掉主因是php-fpm进程过多、opcache配置不当、composer自动加载冗余及调试功能未关闭；应调pm.max_children=4、opcache.memory_consumption=64、启用classmap优化并禁用xdebug等。
PHP-FPM 进程数设太高，内存直接爆掉
低配服务器（比如 1GB 内存）跑 PHP，最常见死因不是代码慢，而是 php-fpm 启了太多子进程，每个进程常驻占用 20–40MB，开 10 个就吃掉 300MB+，再加 MySQL、Nginx，OOM killer 一发就 kill 掉 php-fpm 进程。
关键不是“能不能跑”，是“怎么让 php-fpm 别抢内存”。重点调三个参数：
-
pm = static或pm = ondemand—— 别用dynamic（默认），它预启一堆空闲进程，纯浪费 -
pm.max_children = 4—— 1GB 机器建议从 4 开始试，够应付小流量；top看php-fpm实际 RSS 总和，别超 500MB -
pm.process_idle_timeout = 10s（仅ondemand有效）—— 空闲 10 秒就回收，比static更省，但首次请求有毫秒级延迟
改完记得 sudo systemctl reload php-fpm，别 restart，避免请求中断。
OPcache 开着但没配对，反而更耗内存
OPcache 不是开了就省内存，配错会多缓存无效脚本、保留过期脚本、甚至重复加载同一份字节码。低配机必须收紧：
立即学习“PHP免费学习笔记（深入）”；
-
opcache.memory_consumption = 64—— 别设 128 或 256，64MB 足够缓存中小型项目全部 PHP 文件 -
opcache.max_accelerated_files = 4000—— 默认 10000，实际项目 rarely 超过 2000 个可执行文件，砍半减少哈希表开销 -
opcache.validate_timestamps = 0—— 线上必须关掉文件时间戳校验，否则每次请求都 stat，既慢又触发额外内存分配 -
opcache.revalidate_freq = 0—— 配合上一条，彻底禁用运行时重载
顺手加一句：opcache.enable_cli = 0，CLI 模式不用 OPcache，省下几 MB。
Composer autoload 加载全量类，启动就占 30MB+
很多 Laravel、Symfony 项目部署时没做优化，composer install --no-dev 是基础，但还不够。真正吃内存的是自动加载器把 vendor 里所有 .php 文件路径全塞进内存哈希表。
两个实操动作：
- 用
composer dump-autoload --optimize --classmap-authoritative（Composer 2.2+）—— 生成扁平 classmap，跳过 PSR-4 动态查找，启动快、内存少 - 删掉不用的包：比如
symfony/debug、monolog/monolog（若没日志需求）、phpunit/phpunit（线上绝不能留） - 检查
vendor/autoload.php是否被多次 require —— 某些老框架或自定义 bootstrap 会重复加载，用get_included_files()快速确认
一个典型现象：memory_get_usage(true) 在 require 'vendor/autoload.php' 后猛增 25MB，优化后可压到 8–12MB。
日志和调试功能不关，半夜偷偷吃光 swap
开发环境开着的 error_log、display_errors、xdebug，上线后哪怕没报错，也会持续写缓冲、预留扩展内存空间。
-
display_errors = Off+log_errors = On—— 错误不打屏，只写日志，且确保error_log = /var/log/php/error.log路径存在、可写 - 彻底卸载
xdebug：sudo apt remove php-xdebug（Debian/Ubuntu），别只注释配置，扩展模块加载本身就要占 10–15MB - 关掉 Laravel 的
APP_DEBUG=true、ThinkPHP 的SHOW_ERROR_MSG—— 这些开关不仅暴露信息，还会启用大量调试中间件和异常渲染器
最容易被忽略的一点：error_log 文件别丢在 /tmp 或根目录，swap 耗尽前，磁盘先被日志写满，导致 PHP 写失败后 fallback 到 stderr，反而触发更多内存分配。
