本文介绍如何使用 lombok 的 `@superbuilder` 注解，让子类 builder 正确继承并初始化抽象父类中的字段，彻底解决手动实现 builder 时父类成员不可见、构造器缺失等问题。
在实现 Builder 模式时，若采用抽象基类（如 CommonValidatorConfig）封装通用配置字段（如 canBeNull、canBeEmpty），并期望子类（如 StringValidatorConfig）通过 Builder 构建实例，传统手动编码或组合 @Builder + @AllArgsConstructor 往往失败——因为子类无法自动继承父类字段，导致生成的构造器无参、Builder 方法无法设置父类属性。
根本原因在于：Lombok 的 @Builder 默认仅作用于当前类，不感知继承关系；而手动编写的泛型 Builder（如问题中 Common
✅ 正确解法：使用 Lombok @SuperBuilder（自 Lombok 1.18.2 起支持，当前已进入稳定推广阶段）。
@SuperBuilder 是专为继承场景设计的构建器注解，它会：
- 自动识别父类字段并将其纳入子类 Builder；
- 为抽象父类生成抽象 Builder 基类；
- 为具体子类生成完整、类型安全的 Builder 实现；
- 避免任何 @SuppressWarnings("unchecked") 和不安全的 return (T) this。
✅ 正确用法（极简版）
@Getter
@SuperBuilder
public abstract class CommonValidatorConfig {
private boolean canBeNull;
private boolean canBeEmpty;
}
@SuperBuilder
public class StringValidatorConfig extends CommonValidatorConfig {
}编译后，StringValidatorConfigBuilder 将天然支持：
StringValidatorConfig config = StringValidatorConfig.builder()
.canBeNull(true)
.canBeEmpty(false)
.build();且 StringValidatorConfig 的私有构造器将自动接收 canBeNull 和 canBeEmpty 参数（无需 @AllArgsConstructor）。
✅ 扩展自定义方法（如 setDefault()）
若需添加领域专属逻辑（如统一设默认值），可在抽象 Builder 中声明：
@Getter
@SuperBuilder
public abstract class CommonValidatorConfig {
private boolean canBeNull;
private boolean canBeEmpty;
// 自定义 Builder 方法（Lombok 会自动合并到生成的 Builder 中）
public static abstract class CommonValidatorConfigBuilder<
C extends CommonValidatorConfig,
B extends CommonValidatorConfigBuilder> {
public B setDefault() {
this.canBeNull = false;
this.canBeEmpty = false;
return self(); // ✅ 安全替代 (B)this —— Lombok 提供的类型安全方法
}
}
} ? self() 是 @SuperBuilder 自动生成的受保护方法，返回 B 类型，完全类型安全，无需强制转换。
⚠️ 注意事项与最佳实践
- 不要混用 @Builder 和 @SuperBuilder：同一类上同时使用会导致冲突。
- 字段必须为 private 或包级私有：@SuperBuilder 依赖字段可见性推导 setter 行为。
- 抽象类必须显式标注 @SuperBuilder：否则子类 Builder 不会继承其字段。
- @SuperBuilder 已非“实验性”：虽然文档仍标 experimental，但社区广泛使用，GitHub issue #2209 明确计划升为 stable，且生成代码零运行时开销、100% 类型安全。
- 调试建议：执行 lombok delombok 查看实际生成代码，验证字段注入与构造逻辑是否符合预期。
✅ 总结
放弃手工维护泛型 Builder 层级——@SuperBuilder 是 Lombok 对继承式构建器模式的优雅终结方案。它消除了样板代码、规避了类型转换风险，并通过静态类型检查保障构建过程的安全性与可维护性。对于所有含公共配置基类的校验器、DTO、策略配置等场景，@SuperBuilder 应作为标准实践直接采用。
