老旧服务器php 7.4内存“只涨不跌”主因是变量引用未断、资源未显式释放、静态/全局数据累积三类问题；unset()仅解绑变量名，不释放内存，闭包捕获、gd句柄、双向引用、残余扩展等均导致zend mm无法回收。
老旧服务器跑PHP 7.4，内存“只涨不跌”不是GC失灵，而是变量、资源、引用三类东西卡在了不该留的位置——尤其在宝塔面板+CLI常驻进程（如Swoole/Workerman）或高并发FPM子进程中，unset()不管用、gc_collect_cycles()没反应，基本都踩在这几处。
为什么 unset($var) 后内存不降
PHP的unset()只断开变量名和值的连接，不等于释放内存。只要还有其他强引用存在，内存就锁死：
-
$hugeData = file_get_contents('/big.log');被闭包、静态属性、全局数组或扩展缓存持有，unset($hugeData)毫无作用 - 对象间双向引用（如
$parent->children[] = $child且$child->parent = $parent），引用计数永不归零 - GD图像资源（
imagecreatefromjpeg()返回的句柄）底层是C malloc分配，Zend MM不管理，必须显式调用imagedestroy() - PHP扩展中混用
malloc()和efree()，导致内存永远无法回收
箭头函数(fn())偷偷吃掉大数组
PHP 7.4的箭头函数会自动按值捕获父作用域所有变量，无需use声明——这是最隐蔽的泄漏源之一：
- 错误写法：
$logs = file('access.log'); $handler = fn() => count($logs);→ 整个日志文件内容被闭包长期持有 - 正确写法：改用传统匿名函数，显式
use仅需字段：$handler = function() use ($logCount) { return $logCount; }; - 用完立刻置空：
$handler = null;，否则闭包本身也会拖住父作用域变量 - 验证方式：
debug_zval_dump($handler)看refcount__gc是否异常高
静态缓存和全局资源必须手动清空
Web SAPI请求结束后符号表重置，但static、global、扩展级静态指针不会清——老旧服务器上这类泄漏累积最快：
- 类内
private static $cache = [];不断[]= $obj，却不设容量上限或清理逻辑 - 宝塔面板里同时装了PHP 7.4和8.1，卸载8.1后其扩展.so文件仍残留在
extension_dir中，被PHP扫描加载并占用内存 - Swoole Worker中把Redis客户端塞进
static $redis，随worker寿命无限累积，必须配合max_requests重启兜底 - CLI脚本中用
mysqli_connect()后没调mysqli_close()，连接资源持续堆积
别只调 memory_limit，先关掉无用扩展
老旧服务器内存紧张，盲目调高memory_limit只是掩盖问题。宝塔环境下更应优先精简：
- 进入宝塔「软件商店」→「PHP管理」→「设置」→「禁用扩展」，只保留
opcache和memcached（或redis），其余如mongo、pgsql、snmp等非必要扩展全部卸载 - 检查
php.ini中是否有多余extension=xxx.so行，注释掉再重启php-fpm-74 - 确认
opcache.enable_cli=0（CLI模式默认关闭，避免干扰调试） - 对长期运行的CLI脚本，在循环末尾加
gc_collect_cycles();，并在关键节点用memory_get_usage(true)打点监控
真正难处理的从来不是单次内存峰值，而是那些每次请求都悄悄多占几KB、几十次后就OOM的“毛细血管级泄漏”——它们藏在static数组里、闭包引用里、GD资源句柄里，不逐层用debug_zval_dump()和ps aux --sort=-%mem交叉验证，光靠unset和重启解决不了。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
