简介当Spring Boot项目使用JPA出现Controller返回JSON报错“Could not write JSON: Infinite recursion”时往往由实体类双向引用引发。这份PDF资源正是针对该StackOverflowError异常的完整排错笔记面向后端Java开发人员尤其适合使用JPA/Hibernate进行关联映射的团队。文档从错误堆栈出发剖析PersistentBag循环链的产生机制详解JsonManagedReference、JsonBackReference、JsonIgnore、JsonIdentityInfo等注解的适用场景与代码写法并额外介绍Spring Boot下自定义ObjectMapper的配置技巧。资源为单个PDF文档共1个文件压缩包仅40KB轻量易读。已有4046人学习该资源可作为日常开发中快速查阅的参考手册。通过对照文档中的方案开发者能准确定位循环引用字段避免盲目注释提升序列化性能与代码可维护性。1. 一次返回 JSON 报错背后是对象图的循环引用后端接口返回 JSON 报 HttpMessageNotWritableException异常信息里挂着 Could not write JSON: Infinite recursion (StackOverflowError)第一反应多数是 Jackson 版本或 HTTP 消息转换器出了问题。实际这个异常只是“门面”真正崩溃的是 JVM 栈实体里的双向关联比如 User 持有 ListHobbyHobby 又持有 UserJackson 默认沿着 getter 一路展开user - hobby - user - hobby直到栈帧耗尽。下面先把递归机制和异常链路说清楚再依次给出注解、DTO、JsonIdentityInfo 三条可落地的 json 转换方案最后用日志统计与请求验证收尾。适合写过 REST 接口但没系统踩过关联实体序列化的后端开发也适合做存量接口重构前先评估影响范围。2. Jackson 为什么会在双向关联上递归成 StackOverflowError2.1 从 getter 链看递归路径Jackson 默认按 getter 对属性做 json 解析与输出。只要属性是普通对象或集合它就会继续向下展开直到遇到标量、空引用或已经配置过的忽略规则。代码里不太容易看出问题因为两个实体单独看都“正常”组合成一个环才出事。public class User { private Long id; private String name; private ListHobby hobbies new ArrayList(); public Long getId() { return id; } public String getName() { return name; } public ListHobby getHobbies() { return hobbies; } } public class Hobby { private Long id; private String tag; private User user; public Long getId() { return id; } public String getTag() { return tag; } public User getUser() { return user; } }当 Jackson 序列化一个 User 对象时先输出 id 和 name然后遍历 hobbies。hobbies 里的每个 Hobby 又有 getUser()于是回到 User接着又开始一轮 id、name、hobbies 的输出。如此反复JSON 树始终无法收敛最终栈溢出。这里的要点是Jackson 并不认识“这个 User 之前已经写过一次”它只认递归调用不会自动把重复对象变成引用能做限定的只有注解、类型或显式的身份标识配置。2.2 异常链要往下看StackOverflowError 才是根因Spring MVC 中控制器方法返回值由 HttpMessageConverter 处理。Jackson 序列化失败后转换器会把异常包装成 HttpMessageNotWritableException 抛给上层。控制台第一眼看到的通常是这样org.springframework.http.converter.HttpMessageNotWritableException: Could not write JSON: Infinite recursion (StackOverflowError); nested exception is com.fasterxml.jackson.databind.JsonMappingException: Infinite recursion (StackOverflowError)把堆栈拖到最后真正的错误是 java.lang.StackOverflowError而且堆栈里会反复出现同一行代码。比如 User.getHobbies() 和 Hobby.getUser() 交替出现很多次。定位时不要只看最上面几行要看循环出现的那个 getter 名那就是断环要下手的位置。异常/错误所在层级排查价值HttpMessageNotWritableExceptionSpring MVC 外层说明输出 JSON 这一步失败JsonMappingExceptionJackson 序列化层包含 Infinite recursion 描述StackOverflowErrorJVM 栈层真正导致失败的根因堆栈里重复 getter 是断环入口排查时不要只看第一行用 caused by 一直往下翻堆栈里会反复出现同一个类名和 getter 名那就是循环的入口。我定位这类问题时的习惯是把堆栈里同一个行号的出现次数统计一下次数最多的就是环的边界。2.3 什么项目更容易踩中不是每个双向关联都会立刻炸。常见触发条件是实体用了 Lombok 的 Data 自动生成 getter写表结构时多对多关系直接双向映射Service 在事务内查询后把实体原样返回给 Controller前端只想要“用户和爱好”的 json 数组但接口把整个对象图都带上了。这三种情况叠加时Infinite recursion 几乎是必现的区别只是接口在压测时暴露还是上线后第一次被真实数据触发。换句话说问题通常不是 Jackson 配置不对而是实体职责过重同一个类既当 ORM 聚合根又当接口出参。3. 注解方案最小改动打断递归环3.1 JsonIgnore 切掉回指字段最直接的改造是让 Hobby 的 user 字段不参与序列化。public class Hobby { private Long id; private String tag; JsonIgnore private User user; }序列化 User 时hobbies 正常展开每个 Hobby 的 user 属性被跳过输出变成“用户 - 爱好列表”的单向 json 结构递归终止。要注意副作用单独查 Hobby 的接口里user 信息也没了如果这个接口还要依赖 user 名称显示就得另外构造查询或在 controller 里手动填充 DTO不能指望注解兼顾两个方向。加 JsonIgnore 之前先确认这个字段在输出侧永远不会被需要否则后续会为了补字段再引入新接口改动面反而扩大。3.2 JsonIgnoreProperties 类上统一声明如果不想在 getter 上逐个加注解或者需要同时忽略多个关联字段可以在类级别写一次。JsonIgnoreProperties({user}) public class Hobby { private Long id; private String tag; private User user; }这个注解的作用和 JsonIgnore 相似但它同时影响序列化和反序列化反序列化时JSON 里即便多传了 user 字段也会被丢弃。对于开放给前端的接口这个特性比 JsonIgnore 更稳能顺手防掉前端回传关联对象覆盖后端逻辑的隐患。唯一需要注意的是字段名拼写必须与实体完全一致类上配置对 IDE 重构的敏感度更高“user”一旦改名注解里的字符串不会跟着改序列化时会报无法识别属性排查路径比 getter 上的注解更长。3.3 用 JsonManagedReference 和 JsonBackReference 表示父子方向这两个注解是成对出现的适合“订单-订单项”“部门-员工”这类明确有父子语义的对象图。public class User { JsonManagedReference private ListHobby hobbies new ArrayList(); } public class Hobby { JsonBackReference private User user; }序列化 User 时hobbies 正常输出所有字段Hobby 里的 user 不参与输出反序列化时JSON 里的 user 数据会被忽略以此避免递归。所以它适合“父查子”的接口不适合“子查父”或用户提交双向 JSON 的场景。如果对象图同时涉及多层关联JsonManagedReference 需要逐层配对漏配一处就会回到原来的递归路径。三种注解的边界用下面这张表格收一下按需求选型时不容易混注解作用位置序列化反序列化适用场景JsonIgnore单个字段/getter忽略忽略某个关联永不输出JsonIgnoreProperties类级别忽略忽略同时忽略多个字段JsonManagedReference集合侧展开还原明确父子关系的输出JsonBackReference回指侧忽略忽略上述场景的配对侧选型建议是临时修接口用 JsonIgnore 或 JsonIgnoreProperties对象图有稳定层级关系用 JsonManagedReference/JsonBackReference如果接口对外的 json 格式和实体结构本来就不同直接跳到下一章的 DTO 方案。4. 更干净的路线DTO 出口、全局配置与 JsonIdentityInfo4.1 DTO 把“实体结构”和“接口 json 格式”分开注解方案的共同问题是实体既要服务于 ORM又要服务于 JSON 输出两套需求挤在同一个类里。接口多起来之后每个关联字段的开关都是隐患。DTO 方案把输出形状从实体里独立出来是最可控的做法。public class UserDTO { private Long id; private String name; private ListHobbyDTO hobbies; // getter/setter 省略 } public class HobbyDTO { private Long id; private String tag; }Service 层把 User 映射成 UserDTOhobbies 只拷贝 id 和 tag不携带回指对象。Controller 返回值类型改为 UserDTOJackson 序列化时接触不到 User 实体循环引用自然不存在。实现上可以用 MapStruct 做字段拷贝实体字段增至几十个时也不会把 mapping 写崩。缺点是要多维护一层类接口边界清楚之后这个成本通常可以接受尤其在前后端联调阶段接口返回什么字段不再依赖实体临时改注解。4.2 全局 Jackson 配置兜底实体已经改不动、又不想动接口签名时可以从 Spring Boot 的 Jackson 全局配置上找缓解办法。spring: jackson: serialization: fail-on-empty-beans: false fail-on-self-references: falsefail-on-empty-beans 允许空对象序列化成空 JSON避免 Hibernate 代理对象被判为“无可用属性”后抛异常fail-on-self-references 关闭自身引用检测但它并不能真正阻止双向递归只是放宽了一部分自引用检查。所以这两个开关只能作为兜底不能替代断环操作。Hibernate 场景还要注意懒加载如果 user 属性是代理对象且 session 已关闭Jackson 访问 getter 可能触发 LazyInitializationException此时需要在事务内输出 DTO或引入 jackson-datatype-hibernate 模块让未初始化的属性直接序列化为 null。配置项默认值作用fail-on-empty-beanstrue空对象是否直接抛 JsonMappingExceptionfail-on-self-referencestrue自引用检测开关WRITE_DATES_AS_TIMESTAMPStrue日期型字段输出为时间戳INDENT_OUTPUTfalse调试时格式化输出 JSON4.3 JsonIdentityInfo关联输出成引用不再展开对象图有些接口确实需要把关联对象的 id 一起给前端但不需要完整对象。此时可以用 JsonIdentityInfo 替代忽略或 DTO。JsonIdentityInfo( generator ObjectIdGenerators.PropertyGenerator.class, property id) public class User { private Long id; private String name; private ListHobby hobbies new ArrayList(); } JsonIdentityInfo( generator ObjectIdGenerators.PropertyGenerator.class, property id) public class Hobby { private Long id; private String tag; private User user; }序列化 User 时第一个 Hobby 展开完整字段之后遇到循环引用位置时Jackson 会输出引用形式例如 user: {id: 1}而不是再次展开整棵 User 树。这样输出的仍是一个完整、可解析的 json 结构。使用前提是实体有稳定且唯一的标识字段如果 id 可能为空引用位置会变成 null前端拿到后无法反查反而比展开更麻烦。它适合对象图大、层级深、前端明确知道按 id 关联查询的场景配合 DTO 一起用也很常见DTO 定义基础字段JsonIdentityInfo 专门处理那些跨层引用。5. 实战定位递归入口并验证修复是否到位5.1 从日志里把递归入口找出来报错出现时先别急着抄注解。把服务端堆栈导出来统计堆栈里“同一个调用点出现次数”出现次数最多的那一行通常就是循环环上的必经之路。以 Spring Boot 默认日志为例异常堆栈会完整输出在 ERROR 级别日志里可直接落到文件做统计。grep -n -A 30 JsonMappingException app.log \ | grep at com.example \ | sed s/^[0-9]*[-:]// \ | sort | uniq -c | sort -rn | head -10这段命令把 JsonMappingException 后的堆栈片段里本项目的调用点按出现次数排序。次数明显高于其他行的那个 getter比如 User.getHobbies()就是递归的入口。通过这种方式可以区分到底该忽略哪一侧理论上断掉任何一侧都能终止递归但日志统计会告诉你先到达哪个方向断在更靠近业务主入口的反方向后续改造更稳。5.2 用请求与解析结果确认 json 格式正常修复完成后用 curl 验证接口输出再用 Python 校验整体可解析性。curl -s http://localhost:8080/api/users/1 -H Accept: application/json -o response.jsonimport json with open(response.json, r, encodingutf-8) as f: data json.load(f) print(json.dumps(data, ensure_asciiFalse)[:500])json.load 能正常完成说明返回内容是可被解析的 json不再出现嵌套无限层级如果后端仍然在递归服务端日志里还会出现新一轮 StackOverflowError此时需要检查是否只改了实体的一侧或者项目里还有其他视图类也引用了同一个实体。更贴近线上的验证方式是直接对接口做一次压力请求比如 ab -n 1000 -c 10观察 99% 响应时间是否稳定递归问题治标不治本时偶发请求会突然出现超时那基本是懒加载代理在序列化阶段被触发而不是断环逻辑没生效。提示连续返回大量列表数据时即使递归已被注解打断也应确认每层关联字段都按需查询避免 N1 查询把接口拖慢序列化异常只是表面对象图加载策略同样要过一遍。本文还有配套的精品资源点击获取
简介当Spring Boot项目使用JPA出现Controller返回JSON报错“Could not write JSON: Infinite recursion”时往往由实体类双向引用引发。这份PDF资源正是针对该StackOverflowError异常的完整排错笔记面向后端Java开发人员尤其适合使用JPA/Hibernate进行关联映射的团队。文档从错误堆栈出发剖析PersistentBag循环链的产生机制详解JsonManagedReference、JsonBackReference、JsonIgnore、JsonIdentityInfo等注解的适用场景与代码写法并额外介绍Spring Boot下自定义ObjectMapper的配置技巧。资源为单个PDF文档共1个文件压缩包仅40KB轻量易读。已有4046人学习该资源可作为日常开发中快速查阅的参考手册。通过对照文档中的方案开发者能准确定位循环引用字段避免盲目注释提升序列化性能与代码可维护性。1. 一次返回 JSON 报错背后是对象图的循环引用后端接口返回 JSON 报 HttpMessageNotWritableException异常信息里挂着 Could not write JSON: Infinite recursion (StackOverflowError)第一反应多数是 Jackson 版本或 HTTP 消息转换器出了问题。实际这个异常只是“门面”真正崩溃的是 JVM 栈实体里的双向关联比如 User 持有 ListHobbyHobby 又持有 UserJackson 默认沿着 getter 一路展开user - hobby - user - hobby直到栈帧耗尽。下面先把递归机制和异常链路说清楚再依次给出注解、DTO、JsonIdentityInfo 三条可落地的 json 转换方案最后用日志统计与请求验证收尾。适合写过 REST 接口但没系统踩过关联实体序列化的后端开发也适合做存量接口重构前先评估影响范围。2. Jackson 为什么会在双向关联上递归成 StackOverflowError2.1 从 getter 链看递归路径Jackson 默认按 getter 对属性做 json 解析与输出。只要属性是普通对象或集合它就会继续向下展开直到遇到标量、空引用或已经配置过的忽略规则。代码里不太容易看出问题因为两个实体单独看都“正常”组合成一个环才出事。public class User { private Long id; private String name; private ListHobby hobbies new ArrayList(); public Long getId() { return id; } public String getName() { return name; } public ListHobby getHobbies() { return hobbies; } } public class Hobby { private Long id; private String tag; private User user; public Long getId() { return id; } public String getTag() { return tag; } public User getUser() { return user; } }当 Jackson 序列化一个 User 对象时先输出 id 和 name然后遍历 hobbies。hobbies 里的每个 Hobby 又有 getUser()于是回到 User接着又开始一轮 id、name、hobbies 的输出。如此反复JSON 树始终无法收敛最终栈溢出。这里的要点是Jackson 并不认识“这个 User 之前已经写过一次”它只认递归调用不会自动把重复对象变成引用能做限定的只有注解、类型或显式的身份标识配置。2.2 异常链要往下看StackOverflowError 才是根因Spring MVC 中控制器方法返回值由 HttpMessageConverter 处理。Jackson 序列化失败后转换器会把异常包装成 HttpMessageNotWritableException 抛给上层。控制台第一眼看到的通常是这样org.springframework.http.converter.HttpMessageNotWritableException: Could not write JSON: Infinite recursion (StackOverflowError); nested exception is com.fasterxml.jackson.databind.JsonMappingException: Infinite recursion (StackOverflowError)把堆栈拖到最后真正的错误是 java.lang.StackOverflowError而且堆栈里会反复出现同一行代码。比如 User.getHobbies() 和 Hobby.getUser() 交替出现很多次。定位时不要只看最上面几行要看循环出现的那个 getter 名那就是断环要下手的位置。异常/错误所在层级排查价值HttpMessageNotWritableExceptionSpring MVC 外层说明输出 JSON 这一步失败JsonMappingExceptionJackson 序列化层包含 Infinite recursion 描述StackOverflowErrorJVM 栈层真正导致失败的根因堆栈里重复 getter 是断环入口排查时不要只看第一行用 caused by 一直往下翻堆栈里会反复出现同一个类名和 getter 名那就是循环的入口。我定位这类问题时的习惯是把堆栈里同一个行号的出现次数统计一下次数最多的就是环的边界。2.3 什么项目更容易踩中不是每个双向关联都会立刻炸。常见触发条件是实体用了 Lombok 的 Data 自动生成 getter写表结构时多对多关系直接双向映射Service 在事务内查询后把实体原样返回给 Controller前端只想要“用户和爱好”的 json 数组但接口把整个对象图都带上了。这三种情况叠加时Infinite recursion 几乎是必现的区别只是接口在压测时暴露还是上线后第一次被真实数据触发。换句话说问题通常不是 Jackson 配置不对而是实体职责过重同一个类既当 ORM 聚合根又当接口出参。3. 注解方案最小改动打断递归环3.1 JsonIgnore 切掉回指字段最直接的改造是让 Hobby 的 user 字段不参与序列化。public class Hobby { private Long id; private String tag; JsonIgnore private User user; }序列化 User 时hobbies 正常展开每个 Hobby 的 user 属性被跳过输出变成“用户 - 爱好列表”的单向 json 结构递归终止。要注意副作用单独查 Hobby 的接口里user 信息也没了如果这个接口还要依赖 user 名称显示就得另外构造查询或在 controller 里手动填充 DTO不能指望注解兼顾两个方向。加 JsonIgnore 之前先确认这个字段在输出侧永远不会被需要否则后续会为了补字段再引入新接口改动面反而扩大。3.2 JsonIgnoreProperties 类上统一声明如果不想在 getter 上逐个加注解或者需要同时忽略多个关联字段可以在类级别写一次。JsonIgnoreProperties({user}) public class Hobby { private Long id; private String tag; private User user; }这个注解的作用和 JsonIgnore 相似但它同时影响序列化和反序列化反序列化时JSON 里即便多传了 user 字段也会被丢弃。对于开放给前端的接口这个特性比 JsonIgnore 更稳能顺手防掉前端回传关联对象覆盖后端逻辑的隐患。唯一需要注意的是字段名拼写必须与实体完全一致类上配置对 IDE 重构的敏感度更高“user”一旦改名注解里的字符串不会跟着改序列化时会报无法识别属性排查路径比 getter 上的注解更长。3.3 用 JsonManagedReference 和 JsonBackReference 表示父子方向这两个注解是成对出现的适合“订单-订单项”“部门-员工”这类明确有父子语义的对象图。public class User { JsonManagedReference private ListHobby hobbies new ArrayList(); } public class Hobby { JsonBackReference private User user; }序列化 User 时hobbies 正常输出所有字段Hobby 里的 user 不参与输出反序列化时JSON 里的 user 数据会被忽略以此避免递归。所以它适合“父查子”的接口不适合“子查父”或用户提交双向 JSON 的场景。如果对象图同时涉及多层关联JsonManagedReference 需要逐层配对漏配一处就会回到原来的递归路径。三种注解的边界用下面这张表格收一下按需求选型时不容易混注解作用位置序列化反序列化适用场景JsonIgnore单个字段/getter忽略忽略某个关联永不输出JsonIgnoreProperties类级别忽略忽略同时忽略多个字段JsonManagedReference集合侧展开还原明确父子关系的输出JsonBackReference回指侧忽略忽略上述场景的配对侧选型建议是临时修接口用 JsonIgnore 或 JsonIgnoreProperties对象图有稳定层级关系用 JsonManagedReference/JsonBackReference如果接口对外的 json 格式和实体结构本来就不同直接跳到下一章的 DTO 方案。4. 更干净的路线DTO 出口、全局配置与 JsonIdentityInfo4.1 DTO 把“实体结构”和“接口 json 格式”分开注解方案的共同问题是实体既要服务于 ORM又要服务于 JSON 输出两套需求挤在同一个类里。接口多起来之后每个关联字段的开关都是隐患。DTO 方案把输出形状从实体里独立出来是最可控的做法。public class UserDTO { private Long id; private String name; private ListHobbyDTO hobbies; // getter/setter 省略 } public class HobbyDTO { private Long id; private String tag; }Service 层把 User 映射成 UserDTOhobbies 只拷贝 id 和 tag不携带回指对象。Controller 返回值类型改为 UserDTOJackson 序列化时接触不到 User 实体循环引用自然不存在。实现上可以用 MapStruct 做字段拷贝实体字段增至几十个时也不会把 mapping 写崩。缺点是要多维护一层类接口边界清楚之后这个成本通常可以接受尤其在前后端联调阶段接口返回什么字段不再依赖实体临时改注解。4.2 全局 Jackson 配置兜底实体已经改不动、又不想动接口签名时可以从 Spring Boot 的 Jackson 全局配置上找缓解办法。spring: jackson: serialization: fail-on-empty-beans: false fail-on-self-references: falsefail-on-empty-beans 允许空对象序列化成空 JSON避免 Hibernate 代理对象被判为“无可用属性”后抛异常fail-on-self-references 关闭自身引用检测但它并不能真正阻止双向递归只是放宽了一部分自引用检查。所以这两个开关只能作为兜底不能替代断环操作。Hibernate 场景还要注意懒加载如果 user 属性是代理对象且 session 已关闭Jackson 访问 getter 可能触发 LazyInitializationException此时需要在事务内输出 DTO或引入 jackson-datatype-hibernate 模块让未初始化的属性直接序列化为 null。配置项默认值作用fail-on-empty-beanstrue空对象是否直接抛 JsonMappingExceptionfail-on-self-referencestrue自引用检测开关WRITE_DATES_AS_TIMESTAMPStrue日期型字段输出为时间戳INDENT_OUTPUTfalse调试时格式化输出 JSON4.3 JsonIdentityInfo关联输出成引用不再展开对象图有些接口确实需要把关联对象的 id 一起给前端但不需要完整对象。此时可以用 JsonIdentityInfo 替代忽略或 DTO。JsonIdentityInfo( generator ObjectIdGenerators.PropertyGenerator.class, property id) public class User { private Long id; private String name; private ListHobby hobbies new ArrayList(); } JsonIdentityInfo( generator ObjectIdGenerators.PropertyGenerator.class, property id) public class Hobby { private Long id; private String tag; private User user; }序列化 User 时第一个 Hobby 展开完整字段之后遇到循环引用位置时Jackson 会输出引用形式例如 user: {id: 1}而不是再次展开整棵 User 树。这样输出的仍是一个完整、可解析的 json 结构。使用前提是实体有稳定且唯一的标识字段如果 id 可能为空引用位置会变成 null前端拿到后无法反查反而比展开更麻烦。它适合对象图大、层级深、前端明确知道按 id 关联查询的场景配合 DTO 一起用也很常见DTO 定义基础字段JsonIdentityInfo 专门处理那些跨层引用。5. 实战定位递归入口并验证修复是否到位5.1 从日志里把递归入口找出来报错出现时先别急着抄注解。把服务端堆栈导出来统计堆栈里“同一个调用点出现次数”出现次数最多的那一行通常就是循环环上的必经之路。以 Spring Boot 默认日志为例异常堆栈会完整输出在 ERROR 级别日志里可直接落到文件做统计。grep -n -A 30 JsonMappingException app.log \ | grep at com.example \ | sed s/^[0-9]*[-:]// \ | sort | uniq -c | sort -rn | head -10这段命令把 JsonMappingException 后的堆栈片段里本项目的调用点按出现次数排序。次数明显高于其他行的那个 getter比如 User.getHobbies()就是递归的入口。通过这种方式可以区分到底该忽略哪一侧理论上断掉任何一侧都能终止递归但日志统计会告诉你先到达哪个方向断在更靠近业务主入口的反方向后续改造更稳。5.2 用请求与解析结果确认 json 格式正常修复完成后用 curl 验证接口输出再用 Python 校验整体可解析性。curl -s http://localhost:8080/api/users/1 -H Accept: application/json -o response.jsonimport json with open(response.json, r, encodingutf-8) as f: data json.load(f) print(json.dumps(data, ensure_asciiFalse)[:500])json.load 能正常完成说明返回内容是可被解析的 json不再出现嵌套无限层级如果后端仍然在递归服务端日志里还会出现新一轮 StackOverflowError此时需要检查是否只改了实体的一侧或者项目里还有其他视图类也引用了同一个实体。更贴近线上的验证方式是直接对接口做一次压力请求比如 ab -n 1000 -c 10观察 99% 响应时间是否稳定递归问题治标不治本时偶发请求会突然出现超时那基本是懒加载代理在序列化阶段被触发而不是断环逻辑没生效。提示连续返回大量列表数据时即使递归已被注解打断也应确认每层关联字段都按需查询避免 N1 查询把接口拖慢序列化异常只是表面对象图加载策略同样要过一遍。本文还有配套的精品资源点击获取
