jpa 默认使用 `@generatedvalue` 时会忽略实体已设置的 id 值，导致手动赋值的 uuid 被覆盖。解决方法是移除 `@generatedvalue` 注解，并确保 id 字段可为空（数据库层面允许 null 或应用层保证非空），从而让 jpa 尊重开发者显式设置的主键值。
在使用 JPA（如 Hibernate）持久化实体时，若希望对 @Id 字段（尤其是 UUID 类型）进行手动赋值而非依赖框架自动生成，关键在于正确配置主键生成策略。当前代码中：
@Id @GeneratedValue(strategy = GenerationType.AUTO) private UUID id;
该配置会强制 JPA 在 save() 时忽略你已设置的 id 值（例如 step.setId(uuid)），转而调用默认策略（可能回退为 UUID 生成器或序列/表生成器），最终导致数据库中存储的是新生成的 UUID，而非预期值。
✅ 正确做法：移除 @GeneratedValue，仅保留 @Id，使主键变为“应用分配”（application-assigned）模式：
@Data
@Builder
@Entity
@Table(name = "steps")
@NoArgsConstructor
@AllArgsConstructor
@EntityListeners(AuditingEntityListener.class)
public class Step implements Serializable {
@Id // ✅ 仅标注为主键，不启用自动生成
private UUID id;
private String action;
private String type;
private String createdBy;
private String modifiedBy;
private String team;
}此时，当你显式设置 ID 并调用 save()：
UUID customId = UUID.fromString("7f173364-1ad9-4e45-94ab-788fb641edb5");
Step step = Step.builder()
.id(customId) // ✅ 显式传入
.action("PROCESS_ORDER")
.type(StepType.STEP.name())
.createdBy("admin")
.modifiedBy("admin")
.team("backend")
.build();
stepRepository.save(step); // ✅ JPA 将使用 customId 插入数据库? 注意事项与最佳实践：
- 数据库约束兼容性：确保对应数据库列（如 PostgreSQL 的 UUID 类型或 MySQL 的 CHAR(36)）不设 DEFAULT 值或自增属性，且允许 NULL（虽然应用层应保证非空）。
- ID 冲突风险：手动管理 UUID 需自行保障唯一性（推荐使用标准 UUID.randomUUID() 或确定性 UUID v5/v3），避免重复插入失败（ConstraintViolationException）。
- 更新场景兼容性：此方式同样适用于 save() 更新操作——只要 id 不为 null，JPA 会执行 UPDATE 而非 INSERT；若 id == null，则按新记录处理（需确保业务逻辑合理）。
- 替代方案（进阶）：若需混合策略（有时自动生成、有时手动指定），可结合 @PrePersist 和空值判断，但通常更推荐统一由应用层控制，逻辑更清晰、可测性更强。
总之，移除 @GeneratedValue 是实现手动 UUID 主键的核心步骤。这是一种完全合法且常用的设计，尤其适用于分布式系统、事件溯源、数据迁移或需要幂等写入的场景——只要确保唯一性与业务一致性，就是一种健壮、可控的主键管理方式。
