PHP 8.5 生产环境内存泄漏须从JIT、OPcache、脚本逻辑、进程行为四层排查：JIT函数数与内存使用持续增长提示编译残留；Runtime缓存反复清空导致OPcache失效和重复解析；memory_get_peak_usage(true)循环压测可识别脚本级稳定内存增长；USS远低于RSS则倾向内存碎片，可用gc_mem_caches()缓解。
PHP 8.5 生产环境内存泄漏排查不能只靠“调大 memory_limit”，得从 JIT、OPcache、脚本逻辑和进程行为四层切入。尤其在 CLI 或常驻进程（如 Swoole、队列消费者）中，JIT 编译残留和缓存失效会引发 RSS 持续上涨，而错误日志可能不报错、只默默生成 core dump。
重点查 JIT 和 OPcache 的协同异常
PHP 8.5 的 JIT 在启用状态下（opcache.jit=1205等）会将热点函数编译为机器码并驻留内存。若函数频繁变更（如模板缓存失效、配置未加载导致重复解析）、或存在深度递归/闭包，JIT 缓冲区可能无法有效复用，造成内存缓慢累积：
- 运行 opcache_get_status() 查看
jit['memory_usage']和jit['function_count']—— 若前者持续增长且远超缓冲区设定（如opcache.jit_buffer_size=256M），说明 JIT 层有泄漏倾向 - 临时禁用 JIT 测试：
opcache.jit=0，观察 RSS 是否回归平稳；若恢复，基本锁定 JIT 相关 - 检查是否启用了
opcache.jit_debug=0x20，它会在 error_log 中输出 JIT 内存分配日志，便于定位哪类函数触发高频编译
确认 Runtime 缓存是否被反复清空
很多框架（如 ThinkPHP、PHPCMS）的 Runtime 目录 是内存泄漏的高发区。生产环境若因配置缺失（如 C('not_first') 始终为 null）、自动加载异常或调试开关残留，会导致每次请求都重建缓存文件——这不仅让 OPcache 失效，还会触发大量文件 I/O 和 PHP 文件解析，间接推高内存：
- 进入对应模块的 Runtime 目录，执行
ls -lt | head -n 5，观察文件修改时间是否高度集中、几乎每秒都在刷新 - 比对 BaseController 或初始化逻辑中是否有
clearstatcache()、unlink()或递归rrmdir()调用，尤其注意是否在非必要位置清空整个 Runtime - 检查
get_included_files()返回数量，若长期 >150，说明自动加载失控，大量文件被重复包含并解析
用 memory_get_peak_usage(true) + 循环压测定位脚本级泄漏
不要依赖单次执行结果。在疑似长生命周期脚本（如队列 worker）中插入打点，并跑 100–500 轮循环：
立即学习“PHP免费学习笔记（深入）”；
- 在循环开始前：$start = memory_get_peak_usage(true)
- 在循环体末尾：$used = memory_get_peak_usage(true) - $start；记录每次差值
- 若差值稳定在 0KB 或小幅波动（±2KB），属正常；若每轮稳定 +8KB、+12KB，则存在真实泄漏
- 重点检查：全局数组追加（
$GLOBALS['log'][] = $data）、PDOStatement 未 close、cURL 句柄未 curl_close()、静态属性未重置
快速验证是否为内存碎片而非泄漏
FPM 请求结束会释放大部分内存，但 CLI/Swoole 进程不会主动归还小块内存给系统。若 RSS 持续上涨，但 USS（独占内存）几乎不变，大概率是内存碎片：
- 用
smem -P php查看 USS 和 PSS，若 USS 占比极低（如 RSS=400MB，USS=12MB），优先怀疑碎片 - PHP 8.0+ 提供 gc_mem_caches()，可手动清理 Zend 内存池中的小块缓存（≤3072 字节）
- 在 Swoole 定时器或队列任务间隙调用一次：
gc_mem_caches();，观察 RSS 是否回落
