在Spring Data JPA的项目里，多对多关系非常常见，比如文章和标签、用户和角色、学生和课程。很多人在写代码时习惯性地new一个关联对象，然后直接加到集合里保存，结果数据库里要么报主键冲突异常，要么堆满了重复数据。问题的根源在于没有正确复用已有的托管实体，而是让Hibernate把它当成了新实体去处理。这篇文章就来系统地聊聊多对多关系下复用已有实体的正确姿势。
为什么总是出现重复数据或主键冲突
先看一段典型的错误代码。假设我们有文章（Post）和标签（Tag）两个实体，一个文章可以有多个标签，一个标签也可以挂在多个文章上。常见的写法是：前端传过来一组标签名，后端直接根据名字new出Tag对象塞进集合：
// 错误示范：每次都new新实体
@Transactional
public void savePost(PostDTO dto) {
Post post = new Post();
post.setTitle(dto.getTitle());
for (String tagName : dto.getTags()) {
Tag tag = new Tag();
tag.setName(tagName); // 直接new，无视数据库里是否已存在
post.getTags().add(tag);
}
postRepository.save(post);
}这段代码在Tag的id是自增主键时不会报错，但每次保存都会往tag表里插一条新记录，哪怕“Java”这个标签已经存在一百次了，它还会插入第一百零一条。数据越积越脏，关联表里也全是冗余关系。
另一种情况是主键由业务指定或者使用了联合唯一约束，这时保存会直接抛出Duplicate entry异常，事务回滚，整个保存操作失败。两种表现的本质原因是一样的：Hibernate判断一个实体是“新的”还是“已存在的”，依据的是id是否为空以及持久化上下文中有没有它。你new出来的对象id为空，Hibernate自然按新实体执行insert。
正确复用实体的三种方法
方法一：先查询再关联
最直接的思路是，关联之前先到数据库里查一遍，存在就用旧的，不存在才创建新的。这里推荐用getJpaReferenceById（旧版本叫getOne或getReferenceById）获取代理对象，它不会真正发SQL，只在访问非主键属性时才加载，性能比findById更好：
@Transactional
public void savePost(PostDTO dto) {
Post post = new Post();
post.setTitle(dto.getTitle());
for (String tagName : dto.getTags()) {
Tag tag = tagRepository.findByName(tagName)
.orElseGet(() -> {
Tag t = new Tag();
t.setName(tagName);
return tagRepository.save(t);
});
post.getTags().add(tag); // 关联的是托管实体
}
postRepository.save(post);
}注意findByName需要你在TagRepository里声明，Spring Data会根据方法名自动生成查询。这种写法逻辑清晰，但标签很多时会发起多次查询，量不大时完全够用。
方法二：重写equals和hashCode
要让“复用”判断更可靠，实体的equals和hashCode必须正确实现。默认的Object身份比较在Hibernate的代理和延迟加载场景下会失效，导致两个代表同一行数据的对象被判为不相等。推荐基于业务键（比如标签名）或id来比较：
@Entity
public class Tag {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;
@Column(unique = true, nullable = false)
private String name;
@Override
public boolean equals(Object o) {
if (this == o) return true;
if (!(o instanceof Tag)) return false;
Tag other = (Tag) o;
return this.id != null
? this.id.equals(other.id)
: this.name.equals(other.getName());
}
@Override
public int hashCode() {
// 使用固定值，避免id生成前后hashCode变化导致Set内部定位失败
return 31;
}
}这里有个细节值得展开：如果把hashCode基于id实现，实体在保存前id为空，保存后被赋值，hashCode随之改变。如果这个对象已经放进了HashSet，位置就错乱了，后续contains判断会出问题。所以常见的折中方案是hashCode返回固定值，让equals承担真正的比较逻辑。
方法三：谨慎使用级联和孤儿删除
多对多关系中的级联策略直接决定了“复用”行为。看一个完整的映射示例：
@Entity
public class Post {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;
@ManyToMany(cascade = {CascadeType.PERSIST, CascadeType.MERGE})
@JoinTable(name = "post_tag",
joinColumns = @JoinColumn(name = "post_id"),
inverseJoinColumns = @JoinColumn(name = "tag_id"))
private Set<Tag> tags = new HashSet<>();
}关键点在cascade的配置。千万不要加CascadeType.REMOVE或ALL。多对多的语义是“解除关系”，不是“删除对方”。如果你删了一篇文章并级联删除标签，而这个标签还被其他文章引用着，要么报外键约束错误，要么把别人的标签悄悄删掉，两种结果都是灾难。正确做法是只配置PERSIST和MERGE，删除文章时Hibernate只清理关联表里的中间记录，标签本身安然无恙。
删除关系时的正确姿势
多对多的删除经常被误解。比如要把某篇文章移除一个标签，正确代码是：
@Transactional
public void removeTagFromPost(Long postId, Long tagId) {
Post post = postRepository.findById(postId)
.orElseThrow(() -> new EntityNotFoundException("文章不存在"));
Tag tag = tagRepository.findById(tagId)
.orElseThrow(() -> new EntityNotFoundException("标签不存在"));
post.getTags().remove(tag); // 只删关联表记录，不删tag本身
// 事务提交时Hibernate自动删除post_tag中的中间行
}前提是Tag的equals实现正确，否则remove会因为找不到相等的元素而静默失败，这是很多人遇到“删不掉”却又没有报错的原因。如果想彻底删除一个标签，需要先遍历所有引用它的文章，把标签从每个集合里移除，最后再删标签本体，这几步必须在同一个事务里完成。
保存顺序与事务边界的注意事项
多对多的双向维护还涉及 owning side（拥有方）的问题。只有拥有方对关联表的变更会生效，另一方只负责同步内存状态。一般建议把@JoinTable放在使用频率更高的一方，并在实体里提供统一的辅助方法，避免两边集合不同步：
public void addTag(Tag tag) {
this.tags.add(tag);
tag.getPosts().add(this);
}
public void removeTag(Tag tag) {
this.tags.remove(tag);
tag.getPosts().remove(this);
}另外，整个“查询旧标签、创建新标签、建立关联”的操作应该放在一个@Transactional方法内完成。如果拆到多个事务里，中途任何一步失败都会留下半成品数据。还要留意并发场景：两个请求同时发现标签不存在并同时插入，会撞上唯一约束。可以在数据库层面加唯一索引兜底，捕获异常后重试查询，或者利用saveAll配合INSERT IGNORE语义的自定义SQL来处理。
总结一下，多对多关系下复用已有实体的核心三步：关联前先查库拿托管实体、给实体写好equals和hashCode、级联只留PERSIST和MERGE。把这三点落实到位，重复数据和主键冲突的问题基本就不会再出现了。
Spring JPA多对多关系实体复用修改时间：2026-09-08 16:35:04