FrankenPHP长连接内存持续上涨主因是逻辑死亡对象被强引用钉住，需监控RSS与memory_get_peak_usage()线性增长、检查静态变量清理、改用WeakMap、避免闭包强引用、显式释放SDK资源并手动触发gc_collect_cycles()验证回收。
盯住真实内存：用系统命令确认泄漏进程
先别进代码，用系统工具确认是不是真泄漏：
ps aux --sort=-%mem | head -10 —— 找出 RSS 最高、且随时间持续上升的 FrankenPHP worker 进程
smem -P "frankenphp" -c "pid rss pss uss command" —— 查看每个 worker 的实际物理内存（RSS），对比运行时长是否线性增长
如果某个 worker 的 RSS 小时级上涨超 100MB，且重启后归零，基本可锁定为代码级泄漏。
手动触发 GC 并打点峰值内存
FrankenPHP 默认启用 PHP GC，但长连接中 GC 不会自动高频触发。在关键路径末尾（如请求处理完、连接关闭前）加：
gc_collect_cycles();
error_log('peak: ' . memory_get_peak_usage(true), 4);
重点看 memory_get_peak_usage(true) 是否随连接数/请求数线性上升。若 GC 后峰值仍涨，说明有强引用阻止释放。
查循环引用和静态持有：xdebug_debug_zval 是突破口
在疑似泄漏点（如 onOpen/onMessage 回调内）对关键对象做引用分析：
xdebug_debug_zval('connection'); // 或 $this、self::$cache、$timerId 对应对象
关注两个字段：
– refcount：大于 1 且长期不降，说明被多处持有
– is_ref：为 true 表示存在显式引用（如 &$var），易导致残留
常见泄漏结构：
• TcpConnection → 闭包回调 → 持有 $this → 又指向 self::$cache → cache 中又存了该 connection
• 定时器回调 Timer::add(5, [$this, 'tick']) 给实例加了一条无法断开的强引用链
检查高频泄漏源：闭包、定时器、SDK、静态缓存
逐项排查这些“隐形钉子”：
• 闭包：避免在 onMessage 里写 function() use ($bigData) { ... }；改用参数传递或弱引用
• 定时器：所有 Timer::add() 必须配对 Timer::del($id)，onClose 中清空所有关联定时器
• SDK 和连接：Redis 实例需判断 $redis->isConnected() 后再复用，断连后 unset($this->redis)；EasyWeChat/阿里云 SDK 必须调 close() 或 destroy()
• 静态缓存：禁用 self::$connections[] = $conn；改用 WeakMap（PHP 8.0+）或以 $conn->getFd() 为键的标量数组，并在 onClose 中 unset(self::$cache[$fd])
