直接调用xdebug_start_memory_dump()可轻量抓内存泄漏点，它只保存存活zval的引用关系和大小，生成.xdebug文件；需在疑似泄漏前后各打一次快照，对比refcount>1且is_ref===0的对象。
怎么用xdebug_start_memory_dump()抓泄漏点
直接调用 xdebug_start_memory_dump() 是最轻量的内存快照方式，比开 full trace 性能损耗小得多。它不记录每行执行，只在调用时刻保存所有存活 zval 的引用关系和大小，生成 .xdebug 文件供后续分析。
实操建议：
- 在疑似泄漏函数前后各调一次：先
xdebug_start_memory_dump('/tmp/before.xdebug')，执行逻辑后再xdebug_stop_memory_dump()；同理再打一个after.xdebug - 对比两个 dump 文件时，重点关注 refcount > 1 且 is_ref === 0 的对象——它们大概率被意外持有，没被释放
- 注意：PHP 8.6 默认不启用该函数，需在 php.ini 中显式设置
xdebug.mode=develop,off（不能只写 memory），否则会静默失败
为什么xdebug.trace文件里看不到闭包捕获的变量
默认情况下，xdebug_start_trace() 不会记录闭包通过 use 捕获的外部变量，尤其当这些变量是对象时，极易造成「看不见的强引用」，进而阻断 GC。
必须加配置才能暴露问题：
立即学习“PHP免费学习笔记（深入）”；
- 在 php.ini 或运行时用
ini_set('xdebug.collect_params', '4')—— 数值 4 表示收集全部参数（含对象、资源、闭包） - 同时设
xdebug.collect_return=1，否则闭包执行后返回值的引用链也看不到 - 生成 trace 后用
grep -A5 "function_name" /tmp/trace.xt快速定位闭包调用行，检查 use 后面是否带了大对象或 $this
memory_get_usage(true) 和 xdebug 要不要一起用
要，而且必须配合用。单独看 memory_get_usage(true) 只能告诉你“涨了多少”，但不知道“谁占的”；单独看 xdebug dump 又难判断增长是否真实——比如 Zend 内存池缓存会让两次 dump 看似没变，实际已分配新块。
正确做法是分层验证：
- 第一层：用
memory_get_usage(true)在 CLI 下跑 50 轮循环，确认每轮增长是否稳定（如 +8KB/轮） - 第二层：在第 10 轮和第 40 轮分别打 memory dump，用 diff 工具比对新增的 zval 地址和类名
- 第三层：若发现某 class 出现频次激增（如
App\Dto\UserData从 2 个变成 127 个），就去代码里查构造位置和生命周期管理逻辑
别踩这些xdebug内存分析坑
很多开发者开了 xdebug 就以为万事大吉，结果反而掩盖了真问题。
常见误操作：
- 在生产环境开着
xdebug.mode=debug做远程调试——单步执行本身就会让内存翻倍，Fatal error: Allowed memory size exhausted很可能不是你代码的问题，而是 xdebug 自己吃的 - 用
ini_set('xdebug.max_nesting_level', '512')硬扛递归深的问题，却不检查是不是某处__get()触发了无限代理链 - 依赖
__destruct()清理资源，但在 xdebug trace 里发现析构函数根本没被调用——因为对象还被某个未察觉的全局数组或事件监听器持有着 - 忘记关掉
opcache.enable_cli=1的 CLI 场景，导致反复 require 同一文件却不断生成新 opcode 实例，dump 里看到一堆重复的zend_op_array
最常被忽略的是：xdebug 的 memory dump 不显示 C 层资源句柄（如 cURL、PDOStatement），这类泄漏得靠 memory_get_usage(true) + gc_collect_cycles() + 手动检查 fclose()/$stmt->closeCursor() 是否漏调。
