向空表写入SecurityToken实体时JPA抛出DataIntegrityViolationException

1. 先定位约束违反类型 #

DataIntegrityViolationException本质是数据库约束触发的错误，先扒开嵌套异常看具体原因：

• 如果是SQLIntegrityConstraintViolationException，里面会明确标注是唯一键冲突、非空约束未满足还是外键关联失效，这是最直接的排查入口。

2. 实体类与数据库约束校验 #

（1）唯一键约束冲突 #

检查SecurityToken实体是否对user字段配置了唯一约束（比如@Column(unique = true)或类上的@UniqueConstraint(columnNames = "user_id")），同时排查以下场景：

• 删除旧token后未及时提交事务：Hibernate默认延迟执行SQL，若删除操作还在缓存未刷入数据库，直接新建会触发唯一键冲突。解决方式是删除后调用tokenRepository.flush()强制刷库。
• 并发场景下的间隙问题：查询旧token、删除、新建这三步之间，其他线程插入了同用户的token。解决方式是给查询加行锁：

  @Query("SELECT t FROM SecurityToken t WHERE t.user = :user FOR UPDATE")
  SecurityToken findByUserForUpdate(@Param("user") User user);
  

  再用@Transactional包裹整个逻辑，确保查询-删除-新建在同一事务内执行。

（2）非空约束问题 #

检查SecurityToken的必填字段（比如token、expiryDate、user）是否在新建时遗漏赋值，比如代码里只生成了token但没设置过期时间，或者传入的User对象是临时态（仅设置了id未从数据库查询）。

（3）外键约束失效 #

确认SecurityToken关联User的外键配置：

• 若用@ManyToOne，确保User是持久态对象（从数据库查询获取，而非手动new的仅含id的对象），否则数据库找不到对应用户记录会触发外键异常。
• 检查数据库表的外键规则，比如是否设置了ON DELETE RESTRICT，但删除token时用户已被删除（不过你的场景是删除token，这种概率较低）。

3. 业务逻辑的漏洞校验 #

检查你的Service代码逻辑是否存在以下问题：

• 查询旧token时用了非事务查询，导致查到的是脏数据：比如其他线程已经删除了token，但当前线程查到的还是缓存里的旧数据，后续新建就会冲突。
• 删除逻辑未生效：比如旧token的有效性判断有误，导致实际无效的token没被删除，新建时触发唯一键冲突。

4. 数据库层面直接校验 #

直接执行SQL查看表的约束配置：

SHOW CREATE TABLE table_security_token;

确认表的UNIQUE KEY、NOT NULL、FOREIGN KEY规则和实体类配置一致，避免出现实体类没配置但数据库手动加了约束的情况。

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