thinkphp6支撑一万并发不内存泄漏的关键是切断跨请求资源滞留链：swoole需重置容器实例、隔离全局状态、关闭日志缓冲；php-fpm需限制pm.max_requests、禁用runtime干扰、orm即用即弃；数据库须避免全表select、禁用collection持有、改用游标分页。
ThinkPHP6 要支撑一万并发且不出现内存泄漏，关键不在“堆大内存”，而在切断跨请求资源滞留链——尤其在 Swoole 或 PHP-FPM 长生命周期环境下。真实项目中，90% 的“高并发内存上涨”并非代码级泄漏，而是框架对象、容器实例、静态缓存、数据库连接未及时释放导致的累积性占用。
一、先确认是不是真泄漏
别急着改代码，先验证现象本质：
- 用
memory_get_usage(true)在请求入口、中间件、控制器、模型查询后各打一次点，看单次请求内内存是否“只增不减”。若每次请求都从低水位开始，则不是泄漏，是配置或缓存策略问题 - 观察进程维度：用
ps aux --sort=-%mem | head -5查看 php-fpm worker 或 Swoole worker 进程内存是否随运行时长持续上升；若重启后回落，说明是进程级资源滞留，非单请求 bug - 禁用所有自定义中间件和事件监听器，仅保留路由+控制器空逻辑，压测对比内存曲线——快速定位污染源
二、Swoole 环境下必须做的三件事
TP6 + Swoole 是一万并发常见组合，但也是泄漏高发区：
-
重置容器实例缓存：每次请求结束前执行：
$container = think\Container::getInstance();
$container->setInstances([]); // 清空已解析对象（关键！）
foreach ($container->getBindings() as $abstract => $concrete) {
if (!in_array($abstract, ['app', 'think\App', 'think\Request'])) {
$container->forget($abstract);
}
}
?> -
隔离全局状态：Request/Response/Session 默认挂 static::$instance 或 $_SERVER，Swoole 复用进程时会残留。需在 onRequest 或 middleware 中主动重置：
app('request')->reset(); app('response')->clear(); -
关闭自动日志缓冲：File 日志驱动在高并发下会把日志内容暂存在内存，直到 flush 或进程退出。改用
think\log\driver\Stdout或启用 rotate 并设max_files=10
三、PHP-FPM 模式下的关键调优项
适用于 Nginx + PHP-FPM 架构，目标是让每个 worker “轻装上阵”：
-
限制子进程寿命：在
www.conf中设pm.max_requests = 1000（而非默认的 0 或 10w），强制 worker 定期重启释放长期持有的内存 -
关闭 Runtime 缓存干扰：检查 BaseContoller 或中间件中是否有
delRuntime()、clearCache()类逻辑；确保runtime/目录权限正确（www-data 可写），避免因缓存写失败触发重复编译 -
ORM 查询即用即弃：禁止在全局作用域保存
Db::table()->where(...)构建器实例；查完立刻转数组并unset：$list = Db::name('log')->limit(100)->select()->toArray(); unset($list);
四、数据库与分页的隐形陷阱
一万并发下，一个没处理好的查询可能拖垮整个服务：
- 避免
select()全表加载：改用chunk(500, function ($rows) { ... })分批处理，或直接原生 SQL +Db::query() - 禁用 Collection 自动持有上下文：TP6 的
Collection对象内部持有了 Query 实例和 PDOStatement，大量返回时内存翻倍。务必加->toArray() - 分页不用
paginate()做实时 count：对千万级表，改用游标分页（cursor()）或预估总数，避免每次请求都执行SELECT COUNT(*)
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
