Spring Data JPA返回Optional时如何处理FETCH JOIN重复实体？

这个现象的核心原因是Spring Data JPA在单结果查询场景下做了隐式自动去重，该行为是Spring Data单独实现的，和JPA持久化提供者的默认逻辑无关，具体流程如下：

• 方法执行的第一步和返回List<UserDataEntity>的逻辑完全一致：Spring Data将你定义的FETCH JOIN JPQL交给持久化提供者（最常见的是Hibernate）执行，拿到原始结果集。当用户关联2个部门时，原始结果集里确实存在2个指向同一个UserDataEntity实例的引用，完全符合JPA规范中FETCH JOIN会产生父实体重复记录的描述。
• 针对Optional<T>、直接返回实体类型T这类单结果返回场景，Spring Data不会直接调用JPA的Query#getSingleResult()方法——如果直接调用该方法，遇到重复的父实体记录会直接抛出NonUniqueResultException。它的实现是先调用getResultList()拿到完整的原始结果列表，再通过LinkedHashSet对结果做去重：由于重复项本质是同一个实体实例（引用地址相同，就算你基于主键重写了实体的equals/hashCode，也会被判定为重复元素），最终去重后的集合里只会保留1个UserDataEntity实例。
• 去重完成后Spring Data才会做结果数量校验：结果数为0时返回Optional.empty()；结果数为1时将实体包装为Optional返回；只有当去重后仍然存在多个不同主键的实体实例时，才会抛出非唯一查询结果的运行时异常。

注意：这个自动去重逻辑仅在单结果返回场景生效。如果方法返回值是集合类型（比如List、Set），Spring Data会直接返回持久化层给出的原始结果集，不会做自动去重。这类场景下你需要主动在JPQL中添加DISTINCT关键字，即写为SELECT DISTINCT ud FROM UserDataEntity ud JOIN FETCH ...，才能过滤掉重复的父实体引用。

翻下Spring Data JPA的源码就能验证这个逻辑：对应处理逻辑在JpaQueryExecution的SingleResultExecution分支中，整个流程没有黑魔法，只是在JPA返回结果的基础上多做了一层去重和校验而已。

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