Hibernate SessionFactory执行merge后覆盖initialState实体问题排查

• Hibernate Session的持久化对象特性
  若original是通过Hibernate Session加载的（比如session.get()、find()方法），它属于持久化状态，会被Session的一级缓存管理。调用merge(finalState)时，Hibernate会根据主键匹配Session中已有的持久化实例（即你的original），并将finalState的属性值同步到这个实例上。哪怕你传入克隆后的对象，只要finalState的主键与original一致，merge操作就会直接修改Session内的original实例，导致其被patchedData覆盖。

• 克隆操作的局限性
  即便对original和patchedData做了克隆：

  • 浅克隆下，实体的关联对象（如@OneToMany集合、@ManyToOne引用）仍与原对象共享引用，修改patchedData的关联属性会间接影响original的关联对象；
  • 深克隆后，只要merge的对象主键与Session中original的主键一致，Hibernate依然会找到并更新Session内的持久化实例，克隆的副本只是 detached 状态的对象，无法阻止Session中original的修改。

• hibernateEntityAccess.update的内部逻辑问题
  若update方法的逻辑是：先通过setInitial记录original状态，再将patchedData的属性直接合并到original上生成finalState，最后执行merge——那么在merge之前，original的属性已经被patchedData覆盖。这种情况下，克隆传入也无效，因为方法内部直接操作了实例引用或最终关联到了Session中的持久化对象。

• 若需保留original原始状态，先将其转为 detached 状态：调用session.evict(original)后再克隆，此时Session不再管理该实例，merge操作不会影响它；
• 修改hibernateEntityAccess.update逻辑：基于original的克隆副本创建finalState，仅merge这个副本，避免Session中原始的original实例被修改；
• 确保setInitial方法记录的是对象的快照值（如序列化保存原始状态、深克隆后保存），而非对象引用，防止后续对象修改污染快照。

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