在Spring Boot项目里，不同业务表对主键有着截然不同的要求：有的日志表适合用雪花算法，有的配置表希望用数据库自增，还有的对接外部系统必须用UUID。如果把这些规则全写进每一个实体类，重复代码会迅速膨胀。借助面向对象的继承机制，我们可以抽出一个持有ID的基类，把生成动作延迟到子类或专门的策略实现中，从而做到一处定义、多处复用。
一、为什么需要基于继承的ID策略配置
传统做法是在每个@Entity类上直接标@GeneratedValue，并指定策略。这种方式在单种策略满天飞的项目里尚可接受，但一旦引入多种策略并存，开发者就要在十几个实体中反复粘贴相近注解，后期更换算法极其痛苦。继承式方案的核心价值，是把“实体拥有ID”这一共性上浮，把“ID怎么来”这一变性下沉。
从设计原则看，这符合开闭原则：对扩展开放，对修改封闭。新增一种ID生成方式时，只需添加策略类与对应子类（或配置），原有实体基类完全不动。同时，Spring Boot的依赖注入能帮我们在运行时把正确策略塞进基类，避免手动new导致的耦合。
二、抽象基类与ID持有设计
我们先定义一个不带具体生成逻辑的抽象实体父类。它只声明ID字段和获取方式，具体生成器引用由子类通过泛型或模板方法填入。注意这里只是POJO骨架，不绑定任何数据库注解，保证纯Java层面可测。
下面代码展示了一个最简抽象基类，其中idValue用protected暴露给子类，generateId()为抽象方法，强迫子类给出实现。实际项目中可结合JPA的@MappedSuperclass进一步映射。
public abstract class BaseEntity {
protected Long idValue;
public Long getIdValue() {
return idValue;
}
// 子类必须实现具体的ID生成逻辑
public abstract void generateId();
}
2.1 结合JPA的映射父类
若使用Spring Data JPA，推荐用@MappedSuperclass标注，让所有子表继承字段结构。此时ID列仍在库中存在，但生成动作可交给我们自己的策略，而非JPA自带四种。以下示例把生成时机放在持久化前由服务层调用。
import javax.persistence.MappedSuperclass;
import javax.persistence.Column;
@MappedSuperclass
public abstract class JpaBaseEntity {
@Column(name = "id")
protected Long id;
public Long getId() {
return id;
}
public abstract void assignId();
}
三、具体策略与子类实现
有了基类，下一步是给出几种常见生成器。我们可以用独立组件类封装算法，再让子类在assignId中调用对应组件。这样算法本身也能被单元测试覆盖。
3.1 雪花算法策略类
雪花算法生成长整型趋势递增ID，适合分布式。下面简化版只演示结构，真实场景要处理时钟回拨。该组件被Spring管理，方便注入。
import org.springframework.stereotype.Component;
@Component
public class SnowflakeGenerator {
private long lastTimestamp = -1L;
private long sequence = 0L;
public synchronized long nextId() {
long timestamp = System.currentTimeMillis();
if (timestamp < lastTimestamp) {
throw new RuntimeException("时钟回拨异常");
}
if (timestamp == lastTimestamp) {
sequence++;
} else {
sequence = 0L;
}
lastTimestamp = timestamp;
return ((timestamp << 22) | sequence);
}
}
3.2 继承基类的具体实体
业务实体继承JpaBaseEntity，并通过构造注入拿到所需生成器。如此每个实体类清晰地声明自己用哪种ID，阅读代码时一眼可知。
import javax.persistence.Entity;
import org.springframework.beans.factory.annotation.Autowired;
@Entity
public class OrderRecord extends JpaBaseEntity {
@Autowired
private SnowflakeGenerator snowflakeGenerator;
@Override
public void assignId() {
this.id = snowflakeGenerator.nextId();
}
}
3.3 UUID子类示例
对接第三方时常用UUID字符串。我们另写一个子类，注入不同的生成器即可，基类毫无改动。这种分化正是继承配置的优势。
import javax.persistence.Entity;
import org.springframework.beans.factory.annotation.Autowired;
import java.util.UUID;
@Entity
public class ExternalLog extends JpaBaseEntity {
@Autowired
private UuidGenerator uuidGenerator;
@Override
public void assignId() {
// 假设id字段改为String时可调整，此处演示调用
this.id = Long.parseLong(uuidGenerator.randomUuid().replace("-", "").substring(0, 15), 16);
}
}
四、Spring Boot中的灵活配置注入
如果子类很多，每个都写@Autowired略显繁琐。可借助工厂模式，在基类里根据配置key拿到策略。Spring提供ApplicationContextAware或@ConditionalOnProperty实现按配置切换。
4.1 策略工厂示例
工厂读取配置文件中的id.strategy，返回对应Bean。这样即便同一个实体，也能通过profile切换生成器，继承结构依旧稳定。
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.ApplicationContext;
import org.springframework.stereotype.Component;
@Component
public class IdStrategyFactory {
@Autowired
private ApplicationContext context;
public Object getStrategy(String type) {
if ("snowflake".equals(type)) {
return context.getBean(SnowflakeGenerator.class);
} else if ("uuid".equals(type)) {
return context.getBean(UuidGenerator.class);
}
throw new IllegalArgumentException("未知策略");
}
}
4.2 配置驱动基类分配
在抽象基类中不再硬编码生成器，而是留一个setStrategy钩子，由服务层在保存前根据factory配置填入。这样实体类彻底摆脱对具体算法的依赖，只负责持有ID。
public abstract class FlexibleBaseEntity {
protected Long id;
protected Object idStrategy;
public void setStrategy(Object strategy) {
this.idStrategy = strategy;
}
public abstract void assignId();
}
五、方案对比与避坑建议
集中式配置通常在一个AOP切面里统一生成ID，优势是实体零侵入，但劣势是所有实体共用一套逻辑，很难针对单表特殊化。继承式把灵活性还给实体，代价是类数量增加。在多租户系统中，若策略依赖租户ID，务必在assignId中传入租户上下文，否则可能出现A租户用了B租户序列的错位。
另一个常见误区是直接在基类写死@GeneratedValue，然后试图用子类覆盖，结果JPA并不支持注解覆盖父字段策略。因此我们推荐把生成时机移出ORM框架，改由业务层显式调用assignId，既清晰又避开了框架限制。
| 维度 | 集中式AOP | 继承式配置 |
|---|---|---|
| 实体侵入 | 无 | 需继承基类 |
| 单表定制 | 困难 | 容易 |
| 测试复杂度 | 低 | 中 |
六、总结与实践指引
基于继承的ID生成策略配置，本质是用多态替代条件分支。在Spring Boot中配合@MappedSuperclass与工厂注入，可做到新增算法不改旧实体。落地时建议：基类只定义ID持有与抽象分配方法；具体算法做成独立Spring组件；保存前由Service统一触发分配。如此结构清晰，后续维护成本显著低于散落各处的注解配置。
当项目规模扩大，可进一步把策略类型放进元数据表，实现数据库层面的动态切换。但无论怎么演进，继承带来的“共性上浮、变性下沉”思路，都是抵御重复代码的有效屏障。
Spring_BootID生成策略继承配置修改时间：2026-08-04 07:42:16