在 Spring Boot JPA 应用中，若尝试修改已持久化实体的复合主键（如 num、date、typ）中的任意字段，JPA 会抛出 “identifier of an entity was altered” 异常——因为主键在 JPA 生命周期中被视为不可变标识符。
在 spring boot 中，若尝试修改已持久化实体的复合主键（如 `num`、`date`、`typ`）中的任意字段，jpa 会抛出 “identifier of an entity was altered” 异常——因为主键在 jpa 生命周期中被视为不可变标识符。
JPA 规范明确规定：实体的标识符（即主键）一旦被持久化，便不允许在托管状态下被修改。这并非 Spring Data JPA 的限制，而是 Hibernate 等实现对 JPA 标准的严格遵循。当你执行如下操作时：
@Entity
@IdClass(EntityPk.class)
public class MyEntity {
@Id private Long num;
@Id @Temporal(TemporalType.TIMESTAMP) private Date date;
@Id private String typ;
private String value;
// getters/setters...
}
// 错误示例：修改主键字段后直接 save()
MyEntity entity = repository.findById(new EntityPk(1234567L, date1, "12")).orElseThrow();
entity.setNum(1356789L); // ⚠️ 修改主键字段
repository.save(entity); // → 抛出 IllegalArgumentException: identifier of an entity was alteredJPA 持久化上下文会检测到 entity.num 的变更，并拒绝同步该“非法”状态，从而保护数据一致性与关系完整性。
正确处理方式
✅ 方案一：删除旧实体 + 新建实体（推荐，语义清晰）
适用于主键逻辑上代表“新记录”的场景（例如业务中“日期+类型+编号”组合唯一且变更即等价于创建新条目）：
@Transactional
public MyEntity updatePrimaryKey(MyEntity oldEntity, Long newNum, Date newDate, String newTyp) {
// 1. 解除关联（如有外键引用，需先更新或级联处理）
// 2. 删除原实体
repository.delete(oldEntity);
// 3. 创建新实体（保留非主键字段）
MyEntity newEntity = new MyEntity();
newEntity.setNum(newNum);
newEntity.setDate(newDate);
newEntity.setTyp(newTyp);
newEntity.setValue(oldEntity.getValue()); // 复制业务字段
return repository.save(newEntity);
}✅ 方案二：使用原生 SQL 执行 UPDATE（慎用）
仅当必须原地更新主键（如遗留系统兼容）、且能确保无并发冲突和外键约束风险时采用：
@Modifying
@Query(value = "UPDATE my_entity SET num = :newNum, date = :newDate, typ = :newTyp " +
"WHERE num = :oldNum AND date = :oldDate AND typ = :oldTyp",
nativeQuery = true)
int updateCompositeId(@Param("oldNum") Long oldNum,
@Param("oldDate") Date oldDate,
@Param("oldTyp") String oldTyp,
@Param("newNum") Long newNum,
@Param("newDate") Date newDate,
@Param("newTyp") String newTyp);⚠️ 注意事项：
- 原生 SQL 绕过 JPA 一级/二级缓存，需手动清除相关缓存（如 entityManager.clear()）；
- 外键约束可能失败，务必提前检查并迁移关联数据；
- 无法触发 @PreUpdate 等生命周期回调；
- 不适用于启用了乐观锁（@Version）的实体。
最佳实践建议
- ? 设计阶段规避：优先考虑使用代理主键（如 @GeneratedValue 的 id: Long），将业务字段（num, date, typ）设为唯一索引而非主键，从根本上解除变更限制；
- ? 领域建模反思：若业务要求频繁变更“主键组合”，说明该组合可能并非真正意义上的标识符，而应是业务属性——此时应重新评估实体边界与聚合根设计；
- ? 日志与监控：在 @PreUpdate 或自定义拦截器中校验主键字段是否被意外修改，提前失败并告警。
总之，JPA 的主键不可变性是保障数据一致性的基石。面对需求，应优先通过领域建模与架构优化来适配规范，而非绕过它——这才是可持续、可维护的工程实践。
