PHP-FPM子进程内存不会自动释放，ThinkPHP长循环需手动触发gc_collect_cycles()，并配合pm.max_requests限制、内存限制调优及静态属性泄漏防控。
PHP-FPM子进程内存不会自动释放，ThinkPHP长循环必须手动触发GC
PHP-FPM每个worker进程处理完请求后，$_SERVER、$_GET等超全局变量会被重置，但PHP的引用计数和循环引用对象（比如模型关联、闭包、静态属性缓存）并不会被立即回收。ThinkPHP 5.x/6.x中大量使用Container单例、Db::name()链式查询、Collection集合等，若在命令行或长耗时接口中反复执行数据库操作，内存会持续累积——哪怕没报错，memory_get_usage(true)也可能显示增长几十MB。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 在循环体末尾显式调用
gc_collect_cycles()，尤其在for/while中每处理100条数据后触发一次 - 避免在循环内反复调用
new Model()或Db::table()->select()而不释放结果集；改用Db::cursor()流式读取大表 - 清空ThinkPHP内部缓存：对
think\Cache实例调用clear()，或直接Cache::clear()（TP6） - 禁用
opcache.enable_cli=1（CLI模式下OPcache可能干扰GC）
ThinkPHP模型静态属性泄漏是高频内存陷阱
TP5.1+中think\Model类的$connection、$schema、$relation等都是静态属性，一旦某次查询触发了关联预加载（如with('user')），相关模型元信息就会常驻内存。更隐蔽的是Model::get()返回的对象会持有$data、$origin、$relation等大数组，而这些对象若被闭包捕获、存入静态数组或全局缓存，就彻底无法被GC识别。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 禁止在循环中用
Model::create($data)批量创建模型实例；改用Db::insertAll()直写SQL - 主动切断模型引用：
unset($model); $model = null;，再调用gc_collect_cycles() - 检查自定义基类是否在
__construct里注册了App::after()或Event::listen()，这类监听器常带闭包，易造成循环引用 - 用
xdebug_debug_zval()检查关键变量的refcount，确认是否意外被静态容器持有
配置php.ini与FPM pool参数比优化代码更立竿见影
很多团队花几天调Db::chunk()分页逻辑，却忽略FPM子进程本身已分配256MB内存上限——当pm.max_requests = 0时，一个worker可能扛上千次请求，中间任何一次泄漏都会累积。而memory_limit设得过高反而掩盖问题，让GC失效更久。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- FPM pool中强制设置
pm.max_requests = 200~500（不是0），让worker定期重启释放全部内存 -
php.ini中设memory_limit = 128M（非256M），配合log_errors = On和error_log = /var/log/php-fpm-memory.log捕获Fatal error: Allowed memory size of xxx bytes exhausted - 关闭
opcache.save_comments = 0和opcache.load_comments = 0，减少OPcache内存占用 - 禁用
extension=memcached.so等非必要扩展，它们的持久化连接池也占内存
用cli模式复现并验证内存问题最可靠
Web请求受Nginx超时、浏览器中断影响，内存泄漏现象不稳定。而php think test:leak这类命令行脚本能稳定复现——只要memory_get_peak_usage()在第10次循环后比第1次高30%以上，基本可判定存在泄漏。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 写最小复现脚本：只包含
Db::name('user')->select()循环 +memory_get_usage()打印，排除模板、日志等干扰 - 用
php -d memory_limit=64M your_script.php快速触发溢出，定位哪一行首次突破阈值 - 对比开启
zend.enable_gc=1（默认已开）和gc_disable()后的差异，确认是否真由GC机制导致 - TP6中启用
app_debug = true时，Log::record()会缓存全部SQL，记得在cli测试前临时关闭
真正难处理的不是单次溢出，而是那些每次只涨几KB、跑几百次才崩的渐进式泄漏——它往往藏在第三方SDK、自定义事件监听或ORM关联预加载的缝隙里。盯住gc_status()返回的runs和collected字段，比看错误日志更早发现问题。
