PHP 8.2在宝塔中报OOM，主因是php-fpm worker进程RSS内存失控及OPcache配置不当，非memory_limit过低；须关闭opcache.validate_timestamps、禁用xdebug、设pm.max_requests=300并重启服务。
宝塔面板里PHP 8.2报OOM，先别急着调memory_limit
PHP 8.2进程被系统Killed（日志里出现Out of memory: Kill process），大概率不是memory_limit设低了，而是整个php-fpm worker进程RSS内存持续上涨，最终触发Linux OOM Killer。此时哪怕把memory_limit改成2G也没用——进程早被内核干掉了。重点要查的是单个worker实际占多少物理内存、有没有长期驻留的缓存膨胀、以及OPcache是否配置失当。
PHP 8.2的OPcache必须关掉opcache.validate_timestamps和opcache.revalidate_freq
PHP 8.2默认启用OPcache，但宝塔安装后常保留开发模式配置，导致每次请求都检查PHP文件修改时间，不仅拖慢性能，还会在高并发下引发内存碎片累积。尤其当项目含数百个autoload文件时，OPcache元数据区（opcache.memory_consumption）会缓慢泄漏。
-
opcache.validate_timestamps = 0（生产环境必须关） -
opcache.revalidate_freq = 0（配合上一条生效） -
opcache.max_accelerated_files建议设为65536（低于此值会导致频繁哈希冲突重编译） -
opcache.interned_strings_buffer保持16或32（够用即可，设太高反而浪费） - 改完必须执行
bt restart php或在宝塔「软件商店」点PHP 8.2的「重启」
脚本级内存限额不能只靠ini_set()，得看生效层级和CLI/Web差异
在宝塔里跑定时任务（crontab）或命令行脚本时，ini_set('memory_limit', '512M')经常无效，因为CLI SAPI默认读取的是另一套配置，且ini_set()无法突破php.ini里设的硬上限。而Web请求又可能被Nginx的fastcgi_read_timeout或PHP-FPM的request_terminate_timeout提前掐断，看起来像内存溢出。
- CLI脚本最可靠方式：
php -d memory_limit=512M /www/wwwroot/xxx/artisan schedule:run - Web环境优先改
/www/server/php/82/etc/php.ini里的memory_limit = 384M（Laravel类项目）或256M（WordPress） - 禁用
xdebug：检查/www/server/php/82/etc/php.d/15-xdebug.ini是否存在，存在就重命名或删掉——Xdebug开启时单次请求内存开销翻倍 - 确认没重复加载：运行
php -m | grep -E "(xdebug|ioncube|xcache)"，非必要扩展全干掉
查真实内存占用，别信memory_get_usage()返回值
memory_get_usage(true)只反映当前脚本申请的堆内存，对OPcache、PHP-FPM共享内存、扩展私有缓冲区完全不感知。真正要看的是每个worker进程的RSS：
立即学习“PHP免费学习笔记（深入）”；
- 用
ps aux --sort=-rss | grep php-fpm | head -5看top 5个worker实际占多少MB - 如果稳定在80–120MB，
pm.max_children按总内存×0.7÷100算（例如2GB机器设14） - 加
pm.max_requests = 300到/www/server/php/82/etc/php-fpm.d/www.conf，强制worker处理300个请求后重启，防内存缓慢泄漏 - 用
strace -p $(pgrep -f "php-fpm: pool www") -e trace=brk,mmap,munmap抓内存分配行为（仅调试用，别长期开）
OPcache配置错误和PHP-FPM子进程RSS失控，才是宝塔下PHP 8.2内存问题最常被忽略的两个支点。改完参数不重启服务、不验证worker RSS、不关Xdebug，调再多次memory_limit都只是往漏水的桶里加水。
