必须手动配置ObjectNormalizer的circularReferenceHandler回调，仅设setCircularReferenceLimit()无效，因其仅计数不截断，遇双向关联（如User↔Post）仍无限递归致卡死；handler需显式返回安全值（如$id），且ObjectNormalizer须在Serializer中优先注册。
必须手动配置 ObjectNormalizer 的 circularReferenceHandler 回调，否则无论设 setCircularReferenceLimit() 多大、加多少 @Groups 或 @MaxDepth，只要实体存在双向关联（比如 User ↔ Post），序列化就会卡死、白屏、无错误日志——这不是配置遗漏，是机制缺失。
为什么 setCircularReferenceLimit(2) 完全没用
这个方法只在内部计数“当前递归第几层”，但不定义“到第几层该返回什么”。遇到第三层循环时，它不会截断，而是继续尝试访问属性，最终触发 PHP 栈溢出或超时。你看到的“页面卡住”“CPU 100%”“var_dump() 不输出任何东西”，就是它在无限递归。
-
setCircularReferenceLimit()对 Doctrine 双向映射（mappedBy/inversedBy）完全无效，因为循环发生在对象引用层级，不是嵌套深度问题 - 它不抛异常，也不返回占位符，只是硬扛直到崩溃
- 框架默认注册的
serializer服务没配这个 handler，直接$this->serializer注入必然踩坑
怎么写有效的 circularReferenceHandler
handler 是个闭包，接收当前“即将再次出现”的对象，返回你想塞进 JSON 的值（比如 ID、字符串标识，甚至 null）。它必须显式传给 ObjectNormalizer 实例，且该 normalizer 必须在 Serializer 构造时作为第一个参数。
Comprehensive Three.js 3D graphics reference
下载
详细的 Three.js 3D 图形参考，涵盖场景设置、相机、几何体、材质、光照、动画、控制器、加载器、数学工具和调试。
- 最简可用写法：
$normalizer = new ObjectNormalizer(); $normalizer->setCircularReferenceHandler(fn($object) => $object->getId() ?? 'circular-ref'); $serializer = new Serializer([$normalizer], [new JsonEncoder()]);
- 如果还要支持
DateTime或 getter/setter，把DateTimeNormalizer和GetSetMethodNormalizer一起传进去，但ObjectNormalizer必须排第一，否则 handler 不生效 - 别在每个控制器里重复 new —— 封装成服务，例如
App\Serializer\CircularAwareSerializer，用构造器注入所有依赖
Doctrine 实体里哪些注解真能帮上忙
@Ignore 和 @MaxDepth(1) 是少数几个能在属性级起效的控制点，但它们只对当前字段生效，不能替代 circularReferenceHandler。
-
@Ignore直接跳过字段：适合反向引用属性，如Post::$user（当从User序列化时） -
@MaxDepth(1)限制该字段最多展开一层：适合集合类属性，如User::$posts，避免$post->getUser()再次触发循环 -
@Groups只决定字段是否出现，不切断引用链；@SerializedName只改键名，不影响循环 - 调试时别用
dump($entity)—— 改用VarCloner::create()->cloneVar($entity)，它内置循环检测，不会卡死
上线前必须检查的三件事
循环引用问题在开发环境常被内存限制或 Xdebug 拦住，一上生产就暴露：500 错误、慢查询、CPU 爆满。关键检查点不在代码逻辑，而在配置和依赖顺序。
- 确认你用的不是框架默认的
serializer服务，而是自己 new 出来并配了 handler 的实例 - 运行
php bin/console debug:doctrine，检查mappedBy/inversedBy是否配对正确，报告里有warn就得修 - API 响应里别直接扔
Entity对象进JsonResponse—— 即使配了 handler，N+1 加载也可能拖垮性能；优先用 DTO 或toArray()
