不能直接暴露循环引用，但refCount>1且类型为Stub::TYPE_OBJECT是定位循环引用最有效的线索；需调用$cloner->cloneVar($var)触发计数，refCount为克隆快照值，非运行时实时值。
symfony/var-dumper 的 refCount 能直接暴露循环引用吗
不能直接“暴露”，但它是定位循环引用最有效的线索之一。VarCloner 在克隆变量时会为每个对象生成 Stub，并用 refCount 记录该对象被多少个父节点引用。当 refCount > 1 且类型为 Stub::TYPE_OBJECT，基本可判定存在共享或循环引用。
常见错误现象：一个 Doctrine 实体在多次 dump() 后内存不降，gc_collect_cycles() 无效；用 get_defined_vars() 克隆后发现某个 User 对象的 refCount 持续为 3，追踪发现它同时被 $em、$cache 和闭包监听器持有。
- 必须调用
$cloner->cloneVar($var)才能触发完整引用计数逻辑，直接dump($var)不行 -
refCount是克隆时的快照值，不是运行时实时值；需在疑似泄漏点前后分别采集对比 - 注意排除
__sleep()或序列化钩子干扰 —— 它们可能绕过克隆路径，导致refCount偏低
EventDispatcher removeListener 为什么没释放内存
因为 removeListener 只清理了 $listeners 和 $sorted 数组里的条目，但若监听器是闭包，而该闭包又捕获了外部大对象（比如整个 $container 或未 clear() 的 $em），PHP 的 GC 无法回收——闭包本身还活着，捕获的变量就一直被强引用。
使用场景：在命令行 worker 中反复注册/移除监听器处理消息，几万次后 memory_get_usage(true) 持续上涨。
- 优先用类方法而非闭包注册监听器：
[$this, 'onEvent']比function () use ($bigData) { ... }更安全 - 手动打破引用：在
removeListener后，显式将闭包变量设为null，再调用gc_collect_cycles() - 检查
EventDispatcher::$optimized是否残留 —— 这个缓存结构在 Symfony 6.2+ 已默认启用，但未随removeListener自动失效
phpunit 测试中 Doctrine EntityManager 怎么避免累积内存
每次测试用例执行完，$em 默认不会自动 clear() 或关闭，实体仍驻留在一级缓存中，尤其在大量 testXXX() 方法共用同一个 static::$kernel 时，内存只增不减。
错误表现：phpunit --repeat=100 运行后，第 80 次开始报 OutOfMemoryException，而单测通过。
- 在
tearDown()中必须调用$this->em->clear()，不是close()（后者会断开连接，影响后续测试） - 禁用二级缓存：测试环境下设置
doctrine.orm.default_entity_manager.cache.driver: null - 避免在
setUp()中用find()加载大批量实体；改用getReference()或原生 SQL 插入 fixture
Symfony 4.4+ 的 OutOfMemoryException 为何总不触发
因为自 Symfony 4.4 起，Symfony\Component\Debug\Exception\OutOfMemoryException 已被标记为 @deprecated，实际抛出的是 Symfony\Component\ErrorHandler\Error\OutOfMemoryError —— 它是 Error 而非 Exception，且默认不被 try/catch 捕获，也不会走 ExceptionHandler 流程。
这意味着你写的 catch (OutOfMemoryException $e) 永远不会命中，日志里也看不到对应记录。
- 捕获要写成
catch (\Symfony\Component\ErrorHandler\Error\OutOfMemoryError $e) - 更可靠的做法是监控
memory_get_usage(true)阈值，在接近ini_get('memory_limit')前主动exit或throw new \RuntimeException('Memory threshold exceeded') - 注意 CLI 和 FPM 环境差异：FPM 下
OutOfMemoryError可能被 SAPI 层吞掉，建议配合register_shutdown_function()检查error_get_last()
真正难处理的从来不是单次爆内存，而是那种每次请求多占几 KB、跑几十万次才崩的渐进式泄漏——它不会触发 OutOfMemoryError，但会让 gc_collect_cycles() 越来越慢，最终让 memory_get_usage() 返回值看起来“合理”，却再也无法回收。
