Spring Boot中@OneToMany搭配@RestController如何避免JSON无限递归并返回关联Slot列表

你当前遇到的StackOverflowError本质是JPA双向关联触发的Jackson无限递归序列化，序列化路径为：Floor对象 -> slots集合 -> 集合内每个Slot对象 -> 关联的Floor对象 -> 该Floor下的slots集合，循环往复直到内存溢出。你之前在Floor类的slots字段上加的@JsonIgnoreProperties(value= {"floor", "registrations"})没有生效，是因为该注解的作用域是slots这个集合本身，没有触达集合内每个Slot对象的内部属性，无法拦截反向引用的序列化过程。

针对你提出的三个方向，逐一明确适配性：

1. 现有实现逻辑是否正确、仅存在配置问题？ #

现有JPA双向映射的业务逻辑完全符合Hibernate/JPA的规范，不存在设计错误，确实仅序列化配置层面的问题需要调整。
但要注意：哪怕你修正配置解决了循环问题，直接把JPA实体作为API响应返回的长期维护成本极高。

2. 自定义DTO+实体关联字段加@JsonIgnore是否是合理方案？ #

这是生产环境通用的最优实践方向，核心优势包括：

• 解耦数据库实体与API序列化模型，避免实体类上堆砌大量不同接口的Jackson注解，保持实体类纯粹的ORM映射职责
• 杜绝全局序列化规则污染：比如后续开发Slot详情接口时，如果需要返回Slot所属楼层的基础信息，不会被实体类上的全局忽略注解限制
• 灵活控制返回字段范围：可以直接裁剪掉实体中不需要对外暴露的数据库字段（如审计字段、软删标记、临时关联字段），避免敏感数据泄露
  具体落地逻辑为：
• 给实体类的双向关联字段全局添加@JsonIgnore，从根源上禁止JPA实体直接参与序列化时的递归触发
• 在服务层完成实体到DTO的转换：定义FloorDTO包含楼层基础属性+List<SlotDTO>的关联槽位列表，手动组装两个对象的关联关系后再返回给控制层

3. 其他可选实现方案 #

除了DTO方案，还有两种轻量实现方式，但仅适合极简业务场景，长期维护成本较高：

• 修正@JsonIgnoreProperties的放置位置：将注解移到Slot类的floor字段上，标注为@JsonIgnoreProperties("slots")，表示序列化Slot关联的Floor对象时，忽略Floor内部的slots集合，阻断递归路径。缺点是规则全局生效，只要序列化Slot对象，就永远无法返回关联的slots集合，灵活性极差
• 使用Jackson的配对注解：在Floor的slots字段加@JsonManagedReference，在Slot的floor字段加@JsonBackReference，Jackson会自动识别双向关联结构，跳过反向引用的序列化过程。缺点同样是序列化规则硬编码在实体上，遇到多场景不同序列化需求时，需要额外编写大量Mixin规则适配，维护成本高

选型建议：复杂业务系统优先选择DTO转换方案；如果是临时验证、业务逻辑无后续扩展需求，再考虑使用实体类注解快速解决问题。

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