JPA多对多关联下实体图加载异常 序列化出现无限递归

• 懒加载失效的根源是Spring Boot默认开启的*Open Session In View (OSIV)*机制：
  JPA的@ManyToMany关联默认是懒加载策略，JUnit测试场景下你直接在持久化上下文（EntityManager）存活的周期内拿到Repository返回的对象，全程没有主动读取books属性，因此集合不会被初始化，测试结果自然符合预期。
  这里要明确：你在Repository层定义的两个方法，执行查询时的SQL本身完全符合预期——getById生成的查询语句不会关联author_book和book表拉取关联数据。但Web请求链路下，OSIV机制会把EntityManager的生命周期拉长到整个请求完成：当Controller拿到Author对象准备返回时，Jackson序列化器会主动调用所有实体属性的getter方法，一旦触发getBooks()调用，由于EntityManager还处于打开状态，就会立刻发起懒加载查询补全关联数据。无论你调用的是getGraphById还是getById，只要序列化阶段碰到关联属性，就会把关联数据拉回来，最终两个接口返回的结果没有区别。
• 无限递归的成因是双向关联的序列化循环：
  Author类的books和Book类的authors是双向关联，Jackson序列化时会沿着关联链路循环读取：序列化Author→调用getBooks()拿到所有Book→序列化Book→调用getAuthors()拿到所有Author→回到序列化Author的流程，一直循环直到栈溢出。

• 从根源上避免序列化阶段触发懒加载查询
  1. 关闭OSIV机制：在应用配置文件中设置spring.jpa.open-in-view=false，把EntityManager的生命周期严格限定在事务范围内，彻底杜绝序列化阶段随意触发懒加载查询的可能。
  2. 明确事务边界：给Service层的业务方法加上@Transactional注解，在事务范围内完成所有需要的数据库读取操作，不要把没有加工过的持久化对象直接暴露到Controller层做序列化。
  3. 替换实体为专用接口返回DTO：不要直接把JPA实体作为接口返回值，根据接口场景定义对应的返回结构：
     • 对应getById()的简单查询场景，定义只包含id、name字段的AuthorSimpleDTO，不暴露books集合，从结构上避免序列化触碰懒加载属性。
     • 对应getGraphById()的详情查询场景，定义AuthorDetailDTO，关联的Book只保留id、name字段，不把Book里的authors集合暴露给序列化流程。
• 解决双向关联的无限递归问题
  可以根据业务开发节奏选择对应方案：
  1. 基于DTO的结构截断：在定义返回DTO时，不要给双向关联的两端都设置序列化字段，比如BookDTO不包含authors字段，从结构上切断循环链路，这也是长期维护成本最低的方案。
  2. 基于Jackson注解的引用截断：如果短期不想拆DTO，可以在双向关联的属性上加上Jackson的双向引用注解，比如在Author的books属性上加@JsonManagedReference，在Book的authors属性上加@JsonBackReference，告诉Jackson在序列化时截断反向引用，避免循环。
• 代码维护优化：把Author类上定义的@NamedEntityGraph的名称从Book.detail改成Author.detail，匹配定义类的语义，避免后续维护时混淆实体图的定义位置。

内容的提问来源于stack exchange，提问作者jake101