Spring Data JPA中save()与saveAndFlush()均可返回实体ID，二者有何差异？

为什么save()能直接返回实体ID？ #

这本质由JPA主键生成策略和EntityManager的持久化行为决定，和事务提交与否无关：

• 若使用IDENTITY策略（比如MySQL自增主键）：调用EntityManager.persist()时，JPA会立即向数据库发起INSERT请求获取自增ID，并将ID赋值给实体对象，此时不管是否执行flush或commit，实体的ID字段已经有值。Spring Data JPA的save()方法处理新实体时，底层就是调用persist()，因此能直接拿到ID。
• 若使用SEQUENCE策略：JPA会提前从数据库序列中获取下一个值并赋值给实体，这个操作在persist()阶段就完成了，同样不需要等到flush就能拿到ID。
• 仅极少数老旧主键策略（比如早期TABLE策略）可能需要flush后才生成ID，现在这种场景已很少见。

@Transactional是原因吗？ #

Spring Data JPA的Repository方法默认带有@Transactional注解，但这不是save()能返回ID的直接原因。@Transactional的作用是管理事务边界，确保操作在事务上下文内执行，让EntityManager能正常工作；但主键ID的生成时机由JPA的主键策略和persist()行为决定——只要persist()执行完成，ID就会被赋值，和事务是否提交无关。

save()与saveAndFlush()的核心差异 #

二者的区别不在于ID返回时机，而在于是否立即将持久化上下文的变更同步到数据库：

• save()：将实体纳入EntityManager的持久化上下文（managed状态），但不会立即触发数据库SQL执行（除非主键策略要求立即交互）。后续对实体的修改会在事务提交时自动flush到数据库，JPA可能会合并多次修改为更少的SQL语句。
• saveAndFlush()：执行时会立即触发flush操作，把持久化上下文的变更同步到数据库（发送INSERT/UPDATE SQL），但不会提交事务。此时如果事务回滚，数据库中的变更也会被撤销。

举个代码示例：

// save()场景
User user = new User("Alice");
userRepository.save(user);
// 此时user.getId()已赋值，但INSERT SQL可能暂未发送到数据库
user.setEmail("alice@test.com");
// 事务提交时，JPA会合并INSERT和UPDATE操作发送到数据库

// saveAndFlush()场景
User user = new User("Bob");
userRepository.saveAndFlush(user);
// 此时INSERT SQL已发送到数据库，user.getId()已赋值
user.setEmail("bob@test.com");
// 后续需手动flush或等待事务提交，才会将UPDATE同步到数据库

内容的提问来源于stack exchange，提问作者Selim D.