Spring Boot JPA更新User父实体时Friend子记录重复问题解决咨询

出现重复条目并非Hibernate的异常问题，是现有代码三层设计缺陷叠加导致的：

• 声明用了Set<Friend>存储好友关系，但Friend实体没有重写equals和hashCode，默认按对象内存引用判断相等，哪怕字段完全一致的新Friend实例，都会被当成不同元素存入集合，集合自带的去重逻辑完全失效。
• 数据库层面没有针对好友关系的唯一约束，就算应用层漏判，重复数据也能直接写入。
• 实体映射不完整：User侧的@JoinColumn(name = "owner_id")只是在关联注解中声明了外键字段，但Friend实体本身没有映射owner_id字段，Hibernate无法基于该外键做匹配，每次合并更新时都会直接新增关联记录。

1. 补全Friend实体的约束与相等逻辑 #

首先明确业务层唯一规则：同一个用户（owner）下，不能重复添加同一个被关联的好友（userId），基于这个规则做两层保障：数据库层从存储层面杜绝重复数据，Java层修正相等判断逻辑让Set去重能力正常生效。
修改后的Friend实体示例：

@Entity
@Table(
    name = "friends",
    // 对owner_id + user_id 加复合唯一约束，数据库层兜底防重
    uniqueConstraints = @UniqueConstraint(
        columnNames = {"owner_id", "user_id"},
        name = "uk_owner_friend_unique"
    )
)
public class Friend {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private long id;

    // 补上与User侧关联对应的owner_id字段
    @Column(name = "owner_id", nullable = false)
    private long ownerId;

    @Column(name = "user_id", nullable = false)
    private long userId;

    @Column(name = "username", nullable = false, length = 20)
    private String username;

    @Column(name = "email", nullable = false, length = 50)
    private String email;

    // JPA规范要求的无参构造
    public Friend() {}

    // 基于业务唯一键重写equals，禁止使用自增id作为判断依据（新实例id为null，判断失效）
    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        Friend friend = (Friend) o;
        return ownerId == friend.ownerId && userId == friend.userId;
    }

    // hashCode计算逻辑与equals保持一致，保证HashSet去重正常
    @Override
    public int hashCode() {
        return Objects.hash(ownerId, userId);
    }

    // 保留原有getter、setter、业务构造方法
}

注意：绝对不要用自增主键id重写equals和hashCode，客户端传入的新Friend对象在持久化前id为默认值，判断逻辑完全起不到去重作用。

2. 调整User侧的关联与更新逻辑 #

• 保留Set<Friend>的集合类型，修正后的Friend相等逻辑会让集合自动完成去重。
• 调整级联属性，避免无意义的全量级联操作：把CascadeType.ALL改为CascadeType.MERGE, CascadeType.PERSIST，去掉不必要的CascadeType.REMOVE，避免误删已有关联。
• 不要直接用客户端传入的friends集合覆盖数据库中查出的现有User实体的集合，要做增量判断：

// 从数据库中加载待更新的持久化User实体，不要直接使用客户端传入的瞬态对象
User existingUser = userRepository.findById(requestUserId).orElseThrow();
// 先更新User自身的基础字段
existingUser.setUsername(incomingRequest.getUsername());
existingUser.setEmail(incomingRequest.getEmail());
// ... 其他基础字段的更新逻辑

// 增量处理好友集合
for (Friend incomingFriend : incomingRequest.getFriends()) {
    // 填充当前好友关系的所属用户id，匹配数据库唯一约束
    incomingFriend.setOwnerId(existingUser.getId());
    // 因为Friend的equals已经重写，contains方法可以直接判断是否已存在该关系
    if (!existingUser.getFriends().contains(incomingFriend)) {
        existingUser.getFriends().add(incomingFriend);
    } else {
        // 对已存在的好友关系，更新可变的展示字段（用户名、邮箱）
        existingUser.getFriends().stream()
            .filter(existingFriend -> existingFriend.equals(incomingFriend))
            .findFirst()
            .ifPresent(existingFriend -> {
                existingFriend.setUsername(incomingFriend.getUsername());
                existingFriend.setEmail(incomingFriend.getEmail());
            });
    }
}

userRepository.save(existingUser);

禁止直接执行existingUser.setFriends(incomingRequest.getFriends())的覆盖操作：一方面客户端传入的Friend对象是全新实例，直接覆盖会触发Hibernate的级联插入逻辑生成重复记录；另一方面会删除用户已存在但本次请求未携带的好友关联，不符合常规更新语义。

3. 异常兜底处理 #

数据库层的唯一约束会在重复写入时抛出DataIntegrityViolationException，在接口层捕获该异常，直接返回“好友已存在”的提示即可，不需要把异常栈暴露给客户端，也不会产生脏数据。

• 不要只给user_id加唯一约束：好友关系是分属不同owner的，仅靠user_id唯一会导致其他用户无法添加同一个好友的问题，必须用owner_id + user_id的组合唯一约束。
• 不要随意开启orphanRemoval = true：如果开启该属性，集合中被移除的关联记录会被自动删除，全量替换集合时会误删已有好友。
• 客户端传入的日期、字符串类字段要做格式校验，不要依赖JPA的默认类型转换。

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