Hyperf内存泄漏表现为Worker进程内存规律性持续上涨、重启回落，应优先用ps aux定位高内存Worker，检查dispatch_mode配置、协程上下文、静态变量、定时任务及自定义进程资源释放，并借助swoole_tracker、Xdebug、Profiler和PHPStan等工具精准定位根因。
Hyperf内存泄漏不是“偶尔卡一下”，而是Worker进程内存持续上涨、重启后回落、过段时间又飙升——这种规律性增长，基本就是泄漏信号。重点不在“有没有”，而在“从哪开始找”。
看准哪个Worker在扛压
别一上来就翻代码。先用ps aux --sort=-%mem | head -10
确认是不是Worker0独占高内存。如果是，优先检查dispatch_mode是否误配为2（所有请求全发Worker0）；如果不是，再按进程ID逐个盯。加日志时带上posix_getpid()，让每条SQL、每个任务都标清归属Worker，避免日志混杂失焦。
盯死协程上下文和静态变量
协程退出不等于内存释放。常见坑点：
- 用
Context::set()存了大数组或对象，但没配defer清理，协程结束仍驻留内存 - 类里定义
public static $cache = []，每次请求往里塞数据，越积越多 - 自定义进程中用
Coroutine::create()启协程，却忘了Coroutine::close()收尾
这类问题用memory_get_usage(true)在关键节点打点，比盲目猜更直接。
定时任务和自定义进程是重灾区
整点报错、内存随时间线性上涨？大概率是定时任务在“静默吃内存”：
- 分钟级任务本地调成秒级复现，单Worker跑15分钟看内存增幅
- 检查
crontab-dispatcher进程是否存在资源未释放（如PDO连接未close、文件句柄未fclose） - 自定义进程若循环拉取数据，确认是否做了分页+unset中间变量，避免全量加载后长期持有
用对工具，别靠感觉
人工review效率低，工具能快速定位根因：
- 启用swoole_tracker（开启
tracker.enable_malloc_hook=1和tracker.enable_memcheck=1），它能捕获malloc/free不匹配 - 配合
Xdebug生成cachegrind文件，用KCacheGrind看哪段函数堆内存分配最多 - Hyperf内置
Profiler组件打开后，可查单次请求的内存峰值和对象实例数
静态分析别跳过：PHPStan能提前揪出未释放资源的调用链，比如某方法返回Resource却没在调用方close。
