提到 ThinkPHP 在 Swoole 常驻内存下“变胖”，说到底就是进程不销毁，导致那些本该在请求结束时归零的对象、静态变量和单例实例，全赖着不走。你扫一眼 memory_get_usage()，它只涨不跌，最终的结果就是 OOM。说实话，这不是什么稀奇事，只是很多人没想到，PHP 传统模型里“用完即焚”的天然优势，在 Swoole 这里反而成了陷阱。
为什么 Swoole 常驻内存会让 ThinkPHP 变“胖”
ThinkPHP 默认的设计，就是每次 HTTP 请求启动、执行、销毁——所有对象、静态变量、单例实例都在请求结束那一刻自动释放。但 Swoole 启动后，进程常驻，App 实例、Container、数据库连接、日志句柄，甚至你写的 static $cache = []，都不会自动清空。久而久之，内存就像堆雪球一样，只增不减，memory_get_usage() 一路飙升，最终 OOM。这不是理论推演，这是线上实实在在的教训。
哪些地方最容易藏泄漏点
不是所有代码都会泄漏，但下面这几类，特别容易“中招”：
static属性或全局变量（比如缓存数组、计数器）——下次请求直接复用，越积越多。你以为是缓存，其实是内存冲击波。- 未显式关闭的
think\db\Connection或手动 new 的 PDO 实例——Swoole 不会帮你回收连接资源的，你得自己管好。 - 注册了闭包回调但没清理（比如事件监听器、中间件里用
Event::listen()动态注册）——闭包持有了当前上下文引用，整个请求栈都成了“垃圾”，GC 根本绕不开。 - Log 类被反复调用
Log::init()却没重置——底层Handler实例不断叠加，每个都持有文件句柄或 Socket 连接。你每次请求都“初始化”一次，等于多一层引用。
经验表明，大多数泄漏都是这些“显式但没人注意”的点位累积的。手工排查时，优先盯住它们。
怎么安全地在 Swoole 中用 ThinkPHP
核心原则就一条：主动“归零”，而不是依赖销毁。官方 think-swoole 扩展做了部分隔离，但盲区依然存在：
- 每次请求开始前，调用
App::clear()——清除容器绑定、路由规则、钩子事件。但注意，它不清理static属性，这部分得你亲自操刀。 - 数据库连接必须用
Db::connect()->close()或配置'deploy' => 0禁用读写分离连接池——否则连接数会直接爆炸。 - 避免在控制器或服务层写
static $data = []——改用Request::instance()->getCache('key')或 Redis，用请求级的缓存替换静态缓存。 - 日志务必设为按请求生成独立实例：比如
Log::init(['type' => 'file', 'path' => RUNTIME_PATH . 'log/' . date('Ym/d') . '/'])——否则多个请求共用一个 Handler，文件句柄只会越堆越高。
仔细看，这些操作都不是什么高大上的技巧，就是“用完归零”的朴素原则。但在 Swoole 的常驻内存模型下，你不主动做，系统就不会帮你做。
验证泄漏是否真被堵住
别只看单次请求内存，那说明不了什么。要压测，要看趋势。
- 用
ab -n 1000 -c 10 https://127.0.0.1:9501/模拟并发，每 100 次请求后执行php think swoole:status查看 worker 内存。 - 在关键位置加
echo memory_get_usage() . PHP_EOL;，对比第 1 次和第 500 次请求的差值——理想情况应该波动不超过 200KB。 - 注意：
gc_collect_cycles()不会立刻生效。Swoole 下建议每 50 次请求后手动触发一次，但别滥用，它本身也有开销。
最后必须警惕的是：最隐蔽的泄漏往往来自第三方扩展或你自己封装的“工具类”。它们悄悄 hold 住了 Request 或 App 实例，只要进程不死，引用链不断，GC 就绕不开。你排查了半天没发现，不是没泄漏，是你没找到。
