Hyperf自定义Process进程内存持续上涨是因闭包强引用、Context未清理及PDO/文件句柄未关闭所致，需禁用use($this)、显式获取服务、defer清理Context、及时close资源并监控C层分配。
Process进程内存持续上涨，重启才回落
Hyperf自定义Process进程内存随运行时间单向爬升，不是瞬时峰值，而是每小时涨几十MB、几天后OOM Kill——这基本可判定为协程或闭包强引用未断，而非临时分配。Process进程生命周期远长于HTTP Worker（常设为常驻），一旦闭包捕获了大对象（如全量用户列表、原始日志数组、未释放的PDO连接），它就会钉在进程内存里不释放。
闭包use($this)直接拖垮整个DI容器
Process类中常见错误是用Coroutine::create()启动协程时写了use ($this)：
public function handle(): void
{
Coroutine::create(function () use ($this) {
$users = $this->userService->findAll(); // 全量查出10万行
foreach ($users as $user) {
$this->processUser($user); // 每次都带着$this上下文
}
});
}
问题在于：$this指向当前Process实例，而Hyperf默认将Process注册进DI容器，$this又隐式持有Container、Config、Db等全部依赖。一个闭包就能把整个容器实例+所有已加载服务+缓存数据全锁死在内存里。
- 改法：所有依赖显式传参，禁用
use ($this) - 改法：若必须访问服务，用
Container::get(UserService::class)按需获取，不用$this->链式调用 - 改法：大查询结果不存入闭包，改用生成器逐行处理并
unset($row)
Context::set()没配defer，在Process里等于埋雷
Process里调用Context::set('cache', $bigArray)很常见，但Context是协程级存储，而Process进程内可能启动多个协程，且不保证退出顺序。若没配defer，这个$bigArray会一直活在首个协程的上下文中，直到进程重启。
- 错误写法：
Context::set('data', $hugeResult); - 正确写法：
defer(fn () => Context::del('data'));或包裹在try/finally里确保清理 - 更安全做法：Process里避免用
Context存大对象，改用局部变量+明确生命周期管理
没close()的PDO连接和文件句柄在Process里永不释放
Process常用于轮询数据库、读取大文件、消费Kafka等场景。若用了PDO但没调$pdo->close()，或fopen()后忘了fclose()，这些C层资源不会被PHP GC回收，memory_get_usage()完全看不到，但ps aux看到的RSS会稳定上涨。
- 检查点：所有
new PDO()后是否配对close()；所有fopen()后是否配对fclose() - 检查点：用
gc_collect_cycles()+gc_mem_caches()在循环末尾强制触发GC，观察RSS是否回落 - 检查点：用
swoole_tracker开启tracker.enable_malloc_hook=1，确认是否有malloc未匹配free
max_request兜底，它一旦启起来就一直跑。闭包引用、Context残留、未关闭资源，三者叠加，几天内就能把内存吃满。最有效的排查方式，是挑一个高内存的Process进程PID，用ps -o rss= -p PID每30秒采一次，再结合strace -p PID -e trace=malloc,free看C层分配行为——很多泄漏根本不在PHP代码里，而在你没关掉的那个PDO连接背后。 
