内存持续上涨但无oom是典型内存泄露，需用memory_get_usage(true)埋点验证；db::table()->select()返回collection易被意外持有，应转toarray()后unset；xdebug trace可抓内存增长调用链；container::invokefunction隐式持闭包引用需警惕。
内存持续上涨但没明显OOM，先看 memory_get_usage() 和 memory_get_peak_usage()
线上服务跑几天后内存占用越来越高，重启就回落——这是典型的内存泄露信号，但 ThinkPHP 自身不暴露底层引用关系，不能只看日志。得用 PHP 原生函数在关键路径埋点，确认是不是真泄露，而不是短时高峰。
-
memory_get_usage(true)查实际分配的内存页（更准），别只用默认 false 参数 - 在控制器入口、模型查询后、循环结束前各打一次点，用
error_log()写到独立文件，避免和业务日志混在一起 - 注意 CLI 和 FPM 模式差异：FPM 下每个请求是独立进程，内存涨但不跨请求；如果单次请求内多次调用后内存不释放，才是代码级泄露
ThinkPHP 6 的 Db::query() 和 Db::table()->select() 内存表现不同
很多人以为只是写法偏好，其实底层对象生命周期差别很大。用 Db::query() 执行原生 SQL，结果集是数组，查完就扔；而 Db::table()->select() 返回的是 Collection 对象，带迭代器和原始查询上下文，如果没显式销毁或转成数组，可能被闭包、静态变量意外持有。
- 大数据量分页时，优先用
Db::query("SELECT * FROM ... LIMIT ?, ?", [$offset, $limit])，避免Collection累积 - 如果必须用 ORM，查完立刻调用
->toArray()，再 unset 原对象：$data = Db::table('log')->where('status', 0)->select()->toArray(); unset($result); - 别在全局中间件或事件监听器里缓存
Query实例，TP6 的查询构建器不是无状态的
用 Xdebug + trace 模式抓泄露点，但别在生产开 full trace
线上不敢开 profiling，但可以临时启 trace（非 profile），它只记函数调用栈和内存变化，体积小、开销低，适合灰度节点抓 1–2 分钟快照。
- 配置
xdebug.mode=trace，加xdebug.start_with_request=trigger，用 curl 带XDEBUG_TRIGGER=1请求触发 - 生成的 trace 文件用
tracefile-analyzer（PHP 官方小工具）过滤出内存增长 >512KB 的调用链 - 常见陷阱：自定义命令里用了
App::make()获取容器实例，但没释放；或者用think\facade\Cache存了 Closure 或 $this，导致整个控制器实例无法 GC
TP6.1+ 的 Container::getInstance()->invokeFunction() 容易隐式持有了闭包引用
这个方法看着方便，实则危险——它会把传入的闭包绑定到当前容器作用域，如果闭包里用了 $this 或引用了大对象，那个对象生命周期就和容器一样长，直到请求结束甚至更久（尤其在队列任务里）。
- 改用
call_user_func()或直接写函数调用，避开容器注入逻辑 - 如果必须用 invokeFunction，确保闭包是纯函数，不捕获任何外部变量：
fn() => json_encode($data)可以，function () use ($service) { ... }就要小心 - 检查 vendor/topthink/framework/src/think/Container.php 中 invokeFunction 调用位置，尤其是事件回调、中间件 handle 方法里
真正难定位的不是哪行 new 了对象，而是谁悄悄 hold 住了对它的引用。PHP 的 GC 不处理循环引用，TP 的 Facade、Container、Event 这些机制让引用链特别隐蔽。留心闭包、静态属性、全局数组，比优化 SQL 更容易见效。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
