unset()不能立即释放内存，因其仅解除变量名绑定，不归还内存；真正释放需gc回收，而php 8.0常驻进程中gc默认不主动触发，须配合gc_collect_cycles()手动干预并清理强引用与资源。
PHP 8.0 旧系统释放内存不能靠等脚本结束，得主动干预——尤其当它跑在 CLI、Swoole 或长周期任务里时，unset() 和 gc_collect_cycles() 是最直接有效的两个动作，但必须用对时机、断对引用。
为什么 unset() 后内存不降？
因为 unset() 只销毁变量名和当前引用，不等于归还内存。常见失效场景：
-
$obj被其他变量、static属性或全局数组（如$GLOBALS['cache']）强引用着，unset($obj)没用 - 对象间存在循环引用：
$a->b = $b; $b->a = $a;，即使都unset()，GC 也可能延迟或跳过回收 - GD 图像、DOMDocument、cURL 句柄等资源未调用对应销毁函数（如
imagedestroy()、$dom->clear()），底层 C 内存 Zend MM 不管 - 闭包通过
use捕获了大对象，且该闭包被注册为事件监听器或塞进静态容器，生命周期远超预期
CLI 或 Swoole 场景下必须手动触发 GC
PHP 8.0 的 GC 默认只在内存池满或脚本快结束时才运行，对常驻进程完全不可靠。必须显式干预：
- 确保 GC 已启用：
gc_enable();（虽默认开启，但某些旧框架会关掉） - 在批量处理、大循环结束后立即调用：
gc_collect_cycles();，返回值 > 0 表示真清掉了循环引用 - 别只调一次：若循环体大，可在每 N 次迭代后加一次
gc_collect_cycles()，防内存缓存堆积 - 配合
debug_zval_dump($var)查看refcount__gc，确认变量是否还有外部强引用（注意输出里的is_ref__gc为 1 时 GC 失效）
哪些资源必须显式销毁，PHP 不会自动管
这类资源的内存不在 PHP 引用计数体系内，漏掉就等于永久泄漏：
- GD 图像：
imagedestroy($image)—— 忘记它，一张 2000×2000 PNG 就多占 12MB RSS - DOM/XML 对象：
$dom->clear();或手动置空子节点引用；部分版本需强制$dom->__destruct(); - PDOStatement 结果集：
$stmt = null;或$stmt->closeCursor();，否则结果集缓存在内存中 - cURL 句柄：
curl_close($ch);，否则底层 socket 和缓冲区不释放 - 自定义静态缓存：
self::$cache = [];或按 key 清理，避免private static $instances = [];无限累积
旧系统升级前的兜底操作
PHP 8.0 旧系统往往混用大量第三方库（如旧版 PhpSpreadsheet、PHPExcel、Guzzle 6），它们内部容易形成隐性引用链。在无法立刻重构时：
- 用
memory_get_usage(true)在关键路径前后打点，跑 50–100 轮 CLI，确认哪段稳定上涨（+8KB/轮即危险） - 禁用 Xdebug 后再测一次，排除调试器自身开销干扰（Xdebug 7.4+ 在 PHP 8.0 下内存开销显著）
- 临时在
__destruct()里加日志，验证对象是否真被销毁；若没输出，说明仍有外部强引用锁住 - Swoole worker 进程务必配置
max_requests（如 1000），作为泄漏兜底，但不能替代主动释放
最易被忽略的是：静态属性和全局数组在请求间不会重置，而旧系统里大量使用 static $cache 存配置或中间结果，这类泄漏在 FPM 下积累缓慢，在 CLI/Swoole 下几小时就崩。盯住它们，比优化算法更管用。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
