Webman内存泄漏排查需聚焦五方面：一查长生命周期数组是否无限膨胀；二查闭包与循环引用持有；三查第三方SDK资源释放；四用monitor进程实现阈值驱动自愈；五通过压测与二分法定位泄漏接口。
Webman作为常驻内存框架，在提升性能的同时也对内存使用提出了更高要求。若进程内存持续增长且无法回落，可能已出现内存泄漏。以下是针对Webman常驻内存开发中关键注意事项及内存泄漏排查的实操方法：
一、检查长生命周期数组是否无限膨胀
Webman中static、单例属性、global定义的数组属于长生命周期容器，一旦在请求中持续追加数据且从不清理，将直接导致内存泄漏。需重点审查此类结构的写入与清除逻辑。
1、搜索代码中所有static $data = []或protected static $cache等静态数组声明。
2、确认每次请求是否向该数组执行[]=、array_push()或$arr[$key] = $value等写入操作。
3、检查对应位置是否存在匹配的清理机制，例如在请求结束前调用unset(self::$data[$id])或self::$data = []（仅限明确可清空场景）。
4、若该数组用于缓存，请替换为带TTL和容量限制的Webman\Support\Cache实例，而非裸数组。
二、排查闭包与循环引用持有
闭包捕获$this、连接对象、回调上下文后未释放，会阻止GC回收关联对象。尤其在onMessage、onConnect、定时器回调中高发。此类泄漏常表现为memory_get_usage()稳定但RSS持续上涨。
1、定位所有注册于Worker::onWorkerStart、onConnect、onMessage中的匿名函数。
2、检查闭包内是否直接或间接引用了$this、$connection、大型数据对象或数据库连接实例。
3、对必须捕获的连接上下文，改用WeakMap（PHP 8.0+）替代静态数组存储：new WeakMap()，确保对象销毁后引用自动解除。
4、在onClose或任务完成回调中，显式调用gc_collect_cycles()并记录memory_get_peak_usage(true)值，验证是否回落。
三、验证第三方SDK与连接池资源释放
EasyWeChat、Alibaba Cloud SDK、Redis客户端等常在构造时创建长生命周期资源（如HTTP连接、Socket句柄、定时器），若未在生命周期结束时主动关闭，将造成隐式内存驻留。
1、检查所有SDK初始化是否发生在onWorkerStart或构造函数中，而非每次请求内重复new。
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
2、确认SDK文档是否要求手动调用close()、disconnect()或destroy()方法，并在onWorkerStop或连接关闭前执行。
3、对Redis连接，避免在Worker启动时全局new一个实例并长期复用；应改用懒加载+连接健康检测：if (!$this->redis || !$this->redis->isConnected()) { $this->redis = null; }。
4、禁用任何自定义启动脚本中的gc_disable()调用，确保PHP GC全程启用。
四、监控与阈值驱动的进程自愈
Webman自带monitor进程可实时观测各Worker内存占用，当接近memory_limit时自动安全重启。该机制是生产环境第一道防线，但需确保其配置生效且日志可观测。
1、确认php.ini中memory_limit设置合理（建议不低于128M），且未被运行时ini_set('memory_limit', ...)覆盖。
2、检查config/monitor.php中'memory_limit'阈值是否设为0.9 * memory_limit（如memory_limit=128M，则设为115M）。
3、在终端执行php start.php status，确认monitor进程处于listening状态，且无monitor process exited报错。
4、查看runtime/log/monitor.log，确认是否记录类似[INFO] Worker xxx memory usage 116M > limit 115M, restarting...的日志条目。
五、压测定位泄漏接口与二分法代码隔离
当观察到某Worker内存随请求量线性增长（百万级请求后仍持续上升），需通过定向压测锁定问题接口，再以代码隔离方式快速收敛泄漏点。
1、使用ab或wrk对单个路由发起持续压测：wrk -t4 -c100 -d300s http://127.0.0.1:8787/api/leak-test。
2、在压测期间执行ps aux --sort=-%mem | head -n 10，记录目标Worker PID及其RSS变化趋势。
3、确认泄漏复现后，在对应控制器方法起始处插入echo memory_get_usage(true), "\n";并刷新访问，观察输出增幅。
4、对该方法体实施二分注释：每次注释掉约50%的业务逻辑（含模型调用、SDK调用、循环体），保留return response('ok');，重新压测验证RSS是否停止增长。
