Spring Boot+Spring Data+MS SQL：用户插入校验与异常处理

针对你在Spring Boot + Spring Data + MS SQL环境下遇到的用户插入校验、重复数据异常处理问题，我整理了实用的解决思路，帮你覆盖不同场景：

一、最简方式提前校验数据是否符合插入约束（含唯一值） #

要提前确保用户数据满足数据库约束，最直接的方式就是利用Spring Data的查询能力做前置校验，配合实体类的约束注解双重保障：

1. 用Spring Data Repository的exists方法快速校验 #

假设你的User实体中唯一约束字段是username，直接在Repository层定义一个查询方法，Spring Data会自动生成对应的SQL：

public interface UserRepository extends JpaRepository<User, Long> {
    // 针对唯一字段username，判断是否已存在
    boolean existsByUsername(String username);
}

然后在Service层插入前调用这个方法，一旦返回true就直接抛出业务提示：

@Service
public class UserService {
    private final UserRepository userRepo;

    // 构造注入（推荐方式）
    public UserService(UserRepository userRepo) {
        this.userRepo = userRepo;
    }

    public User addUser(User user) {
        // 前置校验唯一字段
        if (userRepo.existsByUsername(user.getUsername())) {
            throw new IllegalArgumentException("该用户名已存在，请更换");
        }
        return userRepo.save(user);
    }
}

⚠️ 注意：这种方式在低并发场景完全够用，但高并发下可能出现竞态问题（两个请求同时校验都通过，最终还是触发数据库唯一约束），此时需要配合数据库锁或者乐观锁来优化。

2. 配合实体类的约束注解做DDL层面保障 #

在User实体的唯一字段上添加@Column(unique = true)，让MS SQL自动创建唯一索引，从数据库层面兜底：

@Entity
@Table(name = "users")
public class User {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Column(unique = true, nullable = false)
    private String username;

    // 其他字段、getter/setter
}

不过要注意：@Column(unique=true)只是DDL层面的约束，不会帮你做运行时的前置校验，所以还是需要配合上面的exists方法做业务层校验。

二、插入重复数据时的异常正确处理 #

即使做了前置校验，高并发场景下还是可能触发数据库的唯一约束异常，这时候需要优雅捕获并处理异常，返回友好提示：

1. 全局异常处理器统一处理（推荐） #

用Spring的@ControllerAdvice定义全局异常处理器，捕获Spring Data抛出的DataIntegrityViolationException（底层是MS SQL的SQLIntegrityConstraintViolationException）：

@ControllerAdvice
public class GlobalExceptionHandler {

    @ExceptionHandler(DataIntegrityViolationException.class)
    public ResponseEntity<String> handleUniqueConstraintViolation(DataIntegrityViolationException ex) {
        String errorMsg = "数据插入失败：";
        // 解析底层SQL异常
        if (ex.getCause() instanceof SQLIntegrityConstraintViolationException sqlEx) {
            // MS SQL中唯一约束冲突的错误码是2601（唯一索引冲突）或2627（主键/唯一约束冲突）
            if (sqlEx.getErrorCode() == 2601 || sqlEx.getErrorCode() == 2627) {
                errorMsg += "该唯一字段值已存在，请更换";
            } else {
                errorMsg += sqlEx.getMessage();
            }
        } else {
            errorMsg += ex.getMessage();
        }
        return ResponseEntity.badRequest().body(errorMsg);
    }
}

这样不管是业务层漏校验，还是高并发竞态导致的异常，都能统一处理，给前端返回清晰的提示。

2. 业务层捕获并转换为自定义异常 #

如果你希望更贴合业务逻辑，可以在Service层捕获异常后，转换成自定义的业务异常，再交给全局处理器处理：

// 先定义自定义异常
public class DuplicateUserException extends RuntimeException {
    public DuplicateUserException(String message) {
        super(message);
    }
}

// Service层处理
public User addUser(User user) {
    try {
        return userRepo.save(user);
    } catch (DataIntegrityViolationException ex) {
        if (ex.getCause() instanceof SQLIntegrityConstraintViolationException sqlEx) {
            if (sqlEx.getErrorCode() == 2601 || sqlEx.getErrorCode() == 2627) {
                throw new DuplicateUserException("用户名已存在，请更换");
            }
        }
        // 其他数据异常抛出通用运行时异常
        throw new RuntimeException("数据插入失败，请稍后重试", ex);
    }
}

// 全局处理器新增对自定义异常的处理
@ExceptionHandler(DuplicateUserException.class)
public ResponseEntity<String> handleDuplicateUser(DuplicateUserException ex) {
    return ResponseEntity.badRequest().body(ex.getMessage());
}

高并发场景额外优化提示 #

如果你的系统是高并发场景，建议在前置校验的基础上，配合悲观锁或者乐观锁：

• 悲观锁：在查询时加写锁，比如在Repository方法上添加@Lock(LockModeType.PESSIMISTIC_WRITE)，确保同一时间只有一个请求能操作该数据。
• 乐观锁：给实体类添加@Version字段，利用数据库的版本控制来避免并发冲突。

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