PHP内存泄漏多因循环引用、静态变量累积或资源未释放导致，非传统堆泄漏；核心是Zend引擎引用计数与GC机制失效场景，如__destruct对象闭环、闭包捕获$this、全局/静态数据堆积及长生命周期资源句柄未显式关闭。
PHP 内存泄漏在实际开发中并不常见，但面试中常被用来考察对底层机制、资源管理和引用计数的理解。核心在于：PHP 的 Zend 引擎使用引用计数（refcount）+ 循环回收（GC）机制管理内存，而“泄漏”往往不是传统意义上的 C 风格堆内存未释放，而是变量或资源长期驻留、无法被 GC 正确回收，导致内存持续增长。
循环引用导致 GC 无法及时回收
PHP 7+ 默认启用 Zend GC，但对复杂嵌套对象的循环引用（尤其是含 __destruct 或闭包的场景），仍可能延迟回收或漏收。
- 典型例子：两个对象互相持有对方的引用，且无外部变量指向它们；若其中任一对象实现了 __destruct，GC 可能将其归入“疑似循环根”，但若结构过深或触发时机未到，内存不会立即释放
- 闭包捕获 $this 时也易形成隐式循环：匿名函数绑定当前对象实例，而该对象又持有该闭包（如作为属性），构成闭环
- 解决思路：手动解除关键引用（如设为 null）、避免在对象中长期存储自身闭包、用 WeakMap（PHP 8.0+）替代强引用缓存
全局变量 / 静态属性持续累积
这类“泄漏”最常见，本质是作用域失控，而非引擎缺陷。
- 将大量数据（如日志、查询结果、临时缓存）不断 push 到 $GLOBALS、类静态数组或 $_SERVER 等超全局变量中，且不清理
- 单例模式滥用：静态实例未提供 reset/clear 方法，或在 CLI 脚本长运行时反复初始化新实例却未销毁旧实例
- 建议：限制静态缓存大小（LRU）、使用弱引用容器、明确生命周期（如请求结束前 flush）
资源未显式释放（Resource 类型）
虽然 PHP 会在脚本结束时自动释放资源（如 file handle、cURL handler、PDOStatement），但在长生命周期场景（如 Swoole Worker、PHP-FPM 持久连接）中必须主动释放。
立即学习“PHP免费学习笔记（深入）”；
- fclose()、curl_close()、$pdo->prepare()->closeCursor() 忘记调用，资源句柄持续占用，间接拖慢内存回收
- PDO 连接未设置 PDO::ATTR_PERSISTENT => false，或未正确复用连接，导致连接池膨胀
- 检查方法：用 get_resources() 查看当前活跃资源类型与数量（PHP 7.3+）
扩展或 C 层代码引发的真实泄漏
纯 PHP 层极少发生真正的内存泄漏，但某些扩展（尤其老旧或非官方扩展）在 C 实现中未配对调用 emalloc/efree，会导致真实堆内存泄漏。
- 典型表现：同一段代码反复执行，memory_get_usage(true) 持续上升，重启 Web Server 后重置
- 排查方式：启用 USE_ZEND_ALLOC=0 + Valgrind（Linux），或用 php --ri opcache 等确认扩展状态
- 应对策略：升级扩展、切换替代方案（如用 ext-redis 替代老版 phpredis）、禁用可疑扩展做隔离测试
面试回答时，重点不是背定义，而是讲清“为什么 PHP 通常不泄漏”“哪些写法会绕过 GC”“如何验证和定位”。多数所谓“泄漏”其实是设计疏忽，而非语言缺陷。
