Spring Boot DELETE接口返回204但未删除数据库记录

1. 排查关联实体与数据库外键约束 #

你的Appliance实体通过room_id关联Room，先去数据库检查appliances表的room_id外键规则——如果外键设置了ON DELETE RESTRICT，虽删除Appliance本身不会被Room关联阻止，但要是存在其他反向关联的错误配置（比如Room的@OneToMany级联策略异常），可能导致删除操作静默失败。

2. 优化删除逻辑，避免操作间隙 #

当前代码先调用existsById再执行deleteById，两个操作之间存在时间窗口，且旧版Spring Data JPA的deleteById不会返回操作结果。改成先查询实体再删除，确保操作原子性：

@DeleteMapping("/{id}")
@Transactional
public ResponseEntity<Void> deleteAppliance(@PathVariable Long id) {
    return applianceRepository.findById(id)
            .map(appliance -> {
                applianceRepository.delete(appliance);
                return ResponseEntity.noContent().build();
            })
            .orElseGet(() -> ResponseEntity.notFound().build());
}

这样能保证查询和删除在同一个事务内，不会出现“查得到但删不掉”的情况。

3. 确认事务是否正常提交 #

虽然加了@Transactional，但仍需检查：

• 是否有未捕获的异常导致事务回滚？（如果有，日志里会有回滚相关记录）
• 开启事务日志排查，在application.yml中添加配置：

logging:
  level:
    org.springframework.transaction: DEBUG
    org.hibernate.transaction: DEBUG

查看日志中是否有committing transaction的记录，如果显示rolling back transaction，顺着日志找具体回滚原因。

4. 强制刷新JPA缓存到数据库 #

JPA的会话缓存可能导致日志显示删除成功，但实际未同步到数据库。可以在删除后手动强制刷新：

applianceRepository.delete(appliance);
applianceRepository.flush(); // 立刻将操作同步到数据库

5. 检查数据源的自动提交配置 #

如果数据源关闭了自动提交，且事务没正确触发提交，也会导致记录残留。确认application.yml里的配置：

spring:
  datasource:
    hikari:
      auto-commit: true # 默认是true，确保这个配置没被改成false

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