Spring JPA多对多关系JSON序列化时已关联对象仅返回ID不输出完整数据

你遇到的序列化异常，直接诱因是Players和Technique实体上配置的@JsonIdentityInfo注解。
这个注解原本是Jackson用来解决双向关联无限递归问题的，核心运行逻辑是：为配置了身份标识（你这里指定的是类的id字段）的类，维护序列化链路级别的已输出对象列表。同一个类的对象第一次被序列化时，会输出完整结构；后续只要对象的标识值匹配已输出列表里的条目，就仅输出对应的标识值，不再展开完整字段。

对应你接口的实际返回流程：

• 序列化ID为12的Player时，关联的id=1（PHP）、id=2（PYTHON）的Technique是首次进入序列化链路，因此会输出完整的技术对象结构
• 遍历到ID为91的Player时，它关联的id=1、id=2的Technique已经被Jackson标记为已输出对象，因此直接输出裸ID值；只有新增关联的id=3（HASKELL）的Technique没有被之前的序列化流程标记过，才会输出完整结构，和你贴的异常返回表现完全吻合。

另外需要说明：你在Technique的反向关联字段ableToUse上已经加了@JsonIgnore，本身就已经阻断了Player和Technique之间的双向递归序列化路径，完全不需要额外引入@JsonIdentityInfo的防递归机制，属于冗余配置带来的副作用。

根据改造成本从低到高，可选以下几种方式：

• 零成本快速修复：直接移除Players和Technique类上的@JsonIdentityInfo注解
  移除后Jackson会正常遍历所有关联的Technique对象，不管这个对象之前有没有在其他Player下出现过，都会输出完整的字段结构。因为已经有@JsonIgnore阻断了反向关联的递归路径，不会出现序列化栈溢出的问题。
• 更规范的长期方案：替换现有的递归防御机制
  如果你不想完全删除防递归的配置，可以把现有配置替换为Jackson专门处理双向关联的注解组合：
  1. 在Players类的canUse字段上添加@JsonManagedReference，标记该端为需要正常序列化的关联主端
  2. 将Technique类的ableToUse字段上的@JsonIgnore替换为@JsonBackReference，标记该端为序列化时跳过的反向关联端
     这种方式不会触发“同对象重复出现就仅输出ID”的副作用，所有关联的Technique对象都会被完整序列化。
• 定制化方案：如果因为其他业务场景必须保留@JsonIdentityInfo的配置，可以给返回Player列表的接口配置独立的序列化上下文，让每个Player的关联集合序列化时不共享全局身份标记，避免跨Player的序列化状态串用。但这种方式改造成本较高，非必要不推荐。

你当前在两个实体的多对多关联上都配置了FetchType.EAGER，当接口返回的Player数据量较大时，很容易触发N+1查询、甚至一次性加载过多关联数据导致内存溢出。后续可以将关联调整为FetchType.LAZY，通过@EntityGraph或者自定义JOIN FETCH查询的方式按需加载关联数据，优化接口性能。

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