在Hibernate里处理自引用的多对多关系，比如药品分组里一个分组可以包含多个子分组，这种场景其实挺常见。但不少开发者会踩中一个“坑”：一不小心，就给同一张关联表配了两个方向相反的@JoinTable。结果就是，Hibernate在生成SQL时直接“懵了”，抛出一个让人摸不着头脑的语法错误，比如ERROR: syntax error at or near "."。问题的核心，往往出在QueryDSL这类工具试图去投影一个因为元数据冲突而未被Hibernate正确识别的集合属性路径上。
✅ 正确的实体映射方式
解决这个问题的关键，在于理清关系的“拥有方”。一个双向的多对多关系，必须且只能有一个方向来定义@JoinTable，这个方向就是拥有方；另一个方向则用mappedBy属性来引用拥有方的那个字段。如果两边都配了@JoinTable，Hibernate就会收到矛盾的指令，不知道该按哪个来生成关联表的操作逻辑，最终导致元数据解析失败和SQL构造错误。
@Entity
@Table(name = "medicaments_group")
@Getter
@Setter
public class MedicamentGroup extends GenericDictionary {
@Id
private Long id;
@Column(name = "group_main")
private boolean groupMain;
@Column(name = "short_name")
private String shortName;
// 拥有方：负责维护关联表，定义 @JoinTable
@ManyToMany(cascade = {CascadeType.PERSIST, CascadeType.MERGE})
@JoinTable(
name = "medicaments_group_join",
joinColumns = @JoinColumn(name = "medicament_group_id"), // 当前分组 ID
inverseJoinColumns = @JoinColumn(name = "medicament_join_id") // 子分组 ID
)
private List childrens = new ArrayList<>();
// 被拥有方：通过 mappedBy 关联到 childrens，不定义 @JoinTable
@ManyToMany(mappedBy = "childrens")
private List childrenOf = new ArrayList<>();
}
⚠️ 这里有几个关键点需要厘清：
childrens字段是关系的拥有方。所有对关联表（medicaments_group_join）的插入和更新操作，都只由这个字段的映射配置来决定。childrenOf字段是纯粹的反向导航属性。它只用于数据读取，其内容会随着childrens集合的变动而自动同步。不过，为了确保双向关系在内存中的一致性，通常建议在业务方法里手动维护一下反向引用。- 只有移除了重复的
@JoinTable声明，QueryDSL或JPQL才能正确地将childrens识别为一个合法的关联路径进行查询。
✅ 安全获取分组及其子分组的推荐方式
映射配对了，查询也得跟上。在QueryDSL里直接select(..., childrens)很容易触发N+1查询问题，或者因为投影异常而失败。更稳妥的做法是使用JPQL的JOIN FETCH子句。它能确保在一次数据库查询中，就加载好主实体及其懒加载的集合，省心又高效。
@Repository
public class MedicamentGroupRepositoryImpl implements MedicamentGroupRepository {
@PersistenceContext
private EntityManager entityManager;
@Override
public List getGroupsAndItsChildren() {
String jpql = """
SELECT DISTINCT mg FROM MedicamentGroup mg
LEFT JOIN FETCH mg.childrens child
WHERE mg.groupMain = false
ORDER BY mg.id
""";
return entityManager.createQuery(jpql, MedicamentGroup.class)
.getResultList();
}
}
LEFT JOIN FETCH：它的作用是强制初始化childrens这个懒加载集合，从而避免后续在Session关闭后访问时抛出LazyInitializationException。DISTINCT：因为JOIN操作可能导致根实体重复，DISTINCT关键字可以帮助去重。不过，Hibernate在将结果封装回实体列表时，通常也会自动处理掉重复的根对象。- 这种方式直接返回完整的实体列表，比用QueryDSL的Tuple手动映射字段更简洁，也规避了字段投影出错的风险。
? 注意事项与最佳实践
把代码跑通只是第一步，要想用得稳，还得注意下面这些细节：
- 别靠“删库重跑”解决问题：有些临时性问题，比如缓存或元数据残留，可能通过重建数据库暂时绕过。但这绝不是解决方案，尤其在生产环境，这相当于掩耳盗铃，根本的映射逻辑缺陷依然存在。
- 级联操作要慎用：在
@ManyToMany上使用CascadeType.ALL风险很高。想象一下，删除一个父分组，结果把所有子分组的关联记录甚至子分组本身都级联删除了，这很可能不是你想要的行为。通常，PERSIST和MERGE已经足够。 - 维护双向关系的一致性：Hibernate不会自动帮你维护内存中双向关系的两端。所以，最好提供一个业务方法来做这件事，例如：
public void addChild(MedicamentGroup child) { this.childrens.add(child); child.childrenOf.add(this); // 维护反向引用 } - 关注性能，尤其是深层嵌套：如果分组关系可能形成非常深的树或无限递归，一次性
JOIN FETCH加载整个树可能导致内存压力。这时需要考虑分页查询、使用@OrderBy控制加载顺序，或者在数据库层面利用CTE（公共表表达式）进行递归查询来优化。
按照上面的思路修正后，你就能稳定地获取到一个List，其中每个分组对象的childrens集合都已被预先加载好，无论是用于后端处理，还是直接提供给前端渲染树形组件，都会顺畅很多。
