FrankenPHP内存泄漏定位需先区分常驻特性与真实泄漏：若内存持续单向增长且不回落，再用memory_get_usage(true)打点、Xdebug内存快照、gc_collect_cycles()验证循环引用、gc_mem_caches()清理小内存碎片。
FrankenPHP 进程内存泄漏的定位，核心在于区分“常驻内存特性”和“真实泄漏”——它本身是常驻进程模型，内存不归还是正常行为；但若内存持续单向增长、不随请求周期回落，才需排查代码级泄漏。工具选择要匹配其运行模式（经典模式 vs Worker 模式）和底层结构（Go + 嵌入 PHP 运行时）。
memory_get_usage(true) + 循环打点：快速确认是否真泄漏
这是第一步，也是最关键的筛选动作。FrankenPHP 的 Worker 模式下，PHP 生命周期不重置，不能依赖“请求结束即清空”来掩盖问题。
- 在 worker 启动后、主循环入口、每轮任务处理前后插入：
echo "mem: " . memory_get_usage(true) . "\n"; - 运行 100–500 轮后观察趋势：若每次增长 5–20 KB 且不回落，基本可判定存在泄漏
- 重点监控位置：数据库查询后、大数组构造后、事件监听注册后、缓存写入后
- 注意：
memory_get_usage(true)返回的是 Zend 内存管理器实际向系统申请的内存块总量，比默认参数更准，能绕过内存池缓存干扰
Xdebug 内存快照（.memprof.out）：定位高耗函数与分配源头
FrankenPHP 完全兼容 Xdebug，只要 PHP 环境启用了它，就能生成精准的内存分配轨迹。适用于定位“谁在反复申请内存”。
- 确保 php.ini 中启用：
zend_extension=xdebug.so和xdebug.mode=develop,memory - 在 worker 主循环内关键位置调用：
xdebug_start_memory_profile()和xdebug_stop_memory_profile() - 用官方
memprof_analyser.php解析生成的.out文件，按 “Total memory allocated” 排序 - 重点关注：框架初始化函数、ORM 关系加载、日志序列化、JSON 编码等高频调用点
gc_collect_cycles() + debug_zval_dump()：验证并打破循环引用
FrankenPHP 的常驻特性会放大 PHP GC 的延迟效应。循环引用（如 Eloquent 模型双向关联、事件监听器闭包捕获）在短生命周期里可能“侥幸存活”，在 Worker 里则直接累积成泄漏。
立即学习“PHP免费学习笔记（深入）”；
- 在怀疑对象作用域结束前，手动调用
gc_collect_cycles()并对比memory_get_usage()变化 - 对可疑变量执行
debug_zval_dump($var)，检查refcount是否异常偏高、is_ref是否为 1 - 修复方式：显式断开引用（
$model->relation = null）、改用WeakReference::create()、避免在闭包中use ($bigObject)
gc_mem_caches()：专治 CLI/Worker 下的小内存碎片
这不是传统意义的“泄漏”，却是 FrankenPHP 用户最常误判的现象：内存持续上涨但找不到大对象——大概率是 PHP 小内存块（
- PHP 8.1+ 原生支持该函数，无需扩展
- 在 FrankenPHP 的定时器中定期调用：
gc_mem_caches();（例如每 100 次请求或每 30 秒一次） - 配合
memory_get_usage(true)观察调用前后下降幅度，可验证是否为碎片问题 - 注意：此函数不影响业务逻辑，只清理 Zend 内存管理器内部的小块缓存
