在 Spring Boot 的 JPA 应用中，若尝试直接修改已持久化实体的复合主键（如 num、date、typ），JPA 会抛出 “identifier of an entity was altered” 异常——因为主键在 ORM 层被严格视为不可变标识符。
在 spring boot 中的 jpa 应用中，若尝试直接修改已持久化实体的复合主键（如 num、date、typ），jpa 会抛出 “identifier of an entity was altered” 异常——因为主键在 orm 层被严格视为不可变标识符。
JPA 规范明确要求：主键（Primary Key）一经分配，即代表该实体的唯一、稳定身份，不得在生命周期内变更。这不仅是 Hibernate/JPA 的实现约束，更是数据库语义与领域建模的基本原则。当您执行如下操作时：
Entity entity = repository.findById(new EntityPk(1234567L, parseDate("2023-02-15 09:00:00"), "12")).orElseThrow();
entity.getPk().setNum(1356789L); // ❌ 危险：直接篡改主键组件
repository.save(entity); // → 抛出 IllegalStateException: "identifier of an entity was altered"
Hibernate 检测到 entityPk 实例内部状态（num 字段）被修改，而其 equals()/hashCode() 行为又依赖这些字段（典型于 @Embeddable 复合主键），便会触发保护机制，拒绝同步“身份漂移”。
✅ 正确处理方式：避免主键变更，采用重建+迁移策略
推荐方案：创建新实体 + 迁移业务关联 + 删除旧实体
@Transactional
public void safelyUpdatePrimaryKey(long oldNum, Date oldDate, String typ,
long newNum, Date newDate, String newTyp) {
// 1. 查询原实体（含关联数据）
Entity oldEntity = repository.findById(new EntityPk(oldNum, oldDate, typ))
.orElseThrow(() -> new EntityNotFoundException("Original entity not found"));
// 2. 构建新主键与新实体（注意：不复用原对象）
EntityPk newPk = new EntityPk(newNum, newDate, newTyp);
Entity newEntity = new Entity(newPk);
newEntity.setOtherFields(oldEntity.getOtherFields()); // 复制非主键属性
// 3. 迁移外键关联（示例：更新 Order 中的 productRef）
orderRepository.updateProductRef(oldPk, newPk); // 使用 @Modifying + native query 或 JPQL
// 4. 保存新实体
repository.save(newEntity);
// 5. 安全删除旧实体（确保无残留引用）
repository.deleteById(oldPk);
}
对应 Order 表的关联更新可定义为：
@Repository
public interface OrderRepository extends JpaRepository<order long> {
@Modifying
@Query("UPDATE Order o SET o.productPk = :newPk WHERE o.productPk = :oldPk")
int updateProductRef(@Param("oldPk") EntityPk oldPk, @Param("newPk") EntityPk newPk);
}</order>
⚠️ 关键注意事项：
- ❌ 禁止重写 @Id 或 @EmbeddedId 对象的 equals()/hashCode() 以“绕过检测”——这将破坏一级缓存与 Session 一致性；
- ✅ 若主键字段存在业务层面的“逻辑变更需求”，应重新审视建模：是否应将 num/date/typ 降级为业务唯一索引（@UniqueConstraint），而引入 @GeneratedValue 的代理主键（如 @Id @GeneratedValue Long id）；
- ? 所有主键重建操作必须包裹在 @Transactional 中，并配合数据库级外键约束（ON UPDATE CASCADE 不适用于 JPA 主键变更场景，慎用）。
总结：JPA 的主键不可变性不是限制，而是保障数据一致性的基石。面对真实业务中“主键需变更”的诉求，本质是模型与现实的错配——优先通过引入代理键、重构业务语义或采用事件驱动的数据迁移模式来解决，而非挑战 ORM 的核心契约。
