当实体 ID 已由应用层（如 UUID）预先生成时，Hibernate 的 save() 会误判为“已存在实体”而执行 UPDATE 而非 INSERT；应改用 persist() 显式声明新实体，或用 merge() 处理可能存在的更新场景。
当实体 id 已由应用层（如 uuid）预先生成时，hibernate 的 `save()` 会误判为“已存在实体”而执行 update 而非 insert；应改用 `persist()` 显式声明新实体，或用 `merge()` 处理可能存在的更新场景。
在使用 Hibernate 进行持久化操作时，save() 方法的行为高度依赖于实体的“状态判定”逻辑：Hibernate 会根据 ID 是否为空（null）以及是否已在当前 Session 中被管理（persistent），来决定执行 INSERT 还是 UPDATE。对于 @Id 字段类型为 UUID 且已显式赋值（如 UUID.randomUUID() 或从请求解析而来）的实体，save() 会跳过 ID 生成阶段，并直接尝试 INSERT —— 但若该 ID 在数据库中尚不存在，理论上应成功插入；而你观察到执行了 UPDATE，说明 Hibernate 实际将该实体识别为了“托管态（detached）或已存在”，常见原因包括：
- 实体曾被加载过并脱离 Session（如缓存复用、跨请求传递），再调用 save() 时 Hibernate 认为其“已存在”；
- 使用了 save() 以外的语义混淆方法（如 update() 或错误地混用 saveOrUpdate()）；
- 更关键的是：save() 并非设计用于预设 ID 的新实体插入 —— 它更适合 ID 由数据库（如 @GeneratedValue）或 Hibernate 自增策略生成的场景。
✅ 正确做法如下：
1. 插入全新实体（ID 已预生成）→ 使用 persist()
persist() 是 JPA 标准方法，明确表示“将一个新实体纳入持久化上下文”，它不会立即分配 ID（对已赋值 ID 无影响），也不会触发 SQL 执行（延迟到 flush 或 commit），且严格保证 INSERT 语义：
// ✅ 推荐：插入带预生成 UUID 的新 Match Match newMatch = new Match(); newMatch.setId(UUID.randomUUID()); // 或从请求解析：UUID.fromString(param) newMatch.setPlayerOne(playerOne); newMatch.setPlayerTwo(playerTwo); newMatch.setWinner(playerOne); session.persist(newMatch); // 明确声明为新实体 // transaction.commit() 触发 INSERT
2. 不确定实体是否已存在 → 使用 merge()
merge() 会先根据 ID 查询数据库：若存在则复制属性并返回托管对象；若不存在则 INSERT 并返回新托管实例。适用于“幂等写入”场景（如 REST API 的 PUT 操作）：
Match detachedMatch = currentMatchService.getMatch(MatchUuid); detachedMatch.setWinner(currentMatch.getPlayerOne()); Match managedMatch = session.merge(detachedMatch); // 安全处理新/旧
⚠️ 注意事项：
- 避免混用 save() 和 persist()：save() 是 Hibernate 特有方法，返回生成的 ID（对 UUID 无意义），而 persist() 更符合 JPA 规范且语义清晰；
- 确保实体未被其他 Session 加载过，否则需显式 evict() 或使用 merge()；
- 若表中存在唯一约束（如 MATCH_ID 主键），INSERT 失败时会抛出 ConstraintViolationException，应捕获并处理；
- H2 内存数据库默认开启 DB_CLOSE_ON_EXIT=false，确保事务提交后数据可见，避免因连接关闭导致“看似未插入”。
总结：对于 ID 由业务层控制的实体，优先使用 persist() 替代 save()；若需兼容“存在即更新、不存在即插入”的语义，则选用 merge()。二者均能准确表达开发者的意图，避免 Hibernate 因 ID 非空而误判状态，从而彻底解决“本该 INSERT 却执行 UPDATE”的问题。
