用 memory_get_usage(true) 在关键节点监控内存，结合 xdebug 追踪引用、手动断开循环引用、及时释放资源句柄，可精准定位并修复 php 内存泄漏。
用 memory_get_usage() 快速定位内存异常增长点
这是最直接、零依赖的排查起点。别等服务崩了才想起来看，**在循环入口、数据库查询前后、大数组构造前后**插入监控，能立刻暴露问题模块。
- 注意区分
memory_get_usage(true)（真实分配内存）和默认调用（当前脚本使用量），后者可能被 Zend 内存池缓存干扰，建议加true参数获取更准数值 - 不要只看单次执行结果——在 CLI 模式下跑 100 轮循环，记录每次
memory_get_usage()差值，若持续上升（如每轮 +12KB），基本可判定泄漏 - 常见误判：没调
unset()就进入下一轮循环，或把大对象塞进全局数组$GLOBALS['cache'][]却不清理
用 Xdebug 追踪堆栈与引用状态
当 memory_get_usage() 锁定可疑函数后，Xdebug 是唯一能告诉你「谁持有了谁」的工具。PHP 8.6 默认启用 xdebug.mode=develop,trace，但必须手动开启内存追踪。
- 在脚本开头加
xdebug_start_trace('/tmp/leak.trace');，结尾加xdebug_stop_trace()，生成的.trace文件里会标记每行代码的内存增减 - 配合
debug_zval_dump($var)查看变量内部引用计数（注意：输出里的refcount是当前值，is_ref为1表示被显式引用，极易导致 GC 失效） - 避坑提示：Xdebug 的 trace 日志默认不记录闭包捕获的变量，需额外开启
xdebug.collect_params=4才能看到use引入的对象是否过大
识别并打破循环引用——特别是对象间双向绑定
PHP 的 GC 能处理简单循环，但在高并发下容易延迟触发，而对象生命周期拉长后，内存就卡住了。PHPCMS、Laravel 早期版本中大量存在 $model->relation 双向持有问题。
- 典型泄漏结构：
$a->b = $b; $b->a = $a;—— 即使unset($a, $b)，只要任一属性仍被其他变量间接引用，GC 就不会回收 - 修复不是靠等 GC：手动断开关键引用，例如
$a->b = null; $b->a = null;，比依赖__destruct()更可靠 - PHP 7.4+ 推荐用
WeakReference::create($obj)替代强引用，尤其适合事件监听器、缓存代理等场景；但注意$weakRef->get()返回null后不可恢复，需做好空值判断
检查资源句柄与扩展层泄漏——常被忽略的「隐性」源头
文件句柄、PDOStatement、cURL 句柄这些资源不释放，不仅占内存，还会耗尽系统 fd 数量。更隐蔽的是某些 PECL 扩展（如旧版 redis、grpc）在 C 层未调用 zval_del_ref 或漏掉 efree()。
立即学习“PHP免费学习笔记（深入）”；
- 数据库场景：PHPCMS 中常见
$this->db->query()后没调$this->db->free_result()，结果集长期驻留内存；PDO 则需确保$stmt = null或显式$stmt->closeCursor() - 文件操作：
fopen()后必须配对fclose()，哪怕只读；用file_get_contents()替代流操作更安全，但要注意它会把整个文件载入内存 - 验证方法：CLI 下执行
lsof -p <pid> | wc -l</pid>，若句柄数随请求稳定增长，大概率是资源未关闭
真正难处理的泄漏往往藏在「多层封装+静态缓存+扩展交互」的组合里，比如一个自定义日志类用静态数组存 WeakReference，但底层扩展又偷偷持有了它的 zval。这种时候，光看 PHP 层代码没用，得结合 strace -e trace=brk,mmap,munmap 看系统调用，再比对 Xdebug trace 和 Blackfire 的内存快照差异。
