通配符不解决Builder链式调用的子类返回类型不匹配问题，真正有效的是泛型自引用设计：基类定义<T extends Builder<T>> T method()，子类继承时绑定自身类型，确保链式调用中每步都返回精确子类类型，维持方法可见性与类型安全。
Java中通配符本身不直接解决Builder链式调用的子类返回类型不匹配问题。真正起作用的是泛型类型参数的协变设计和方法级泛型声明，而非? extends T这类通配符。通配符在Builder场景中通常用于消费端（如接收Builder实例），而不是用于维持链式调用的类型连续性。
为什么通配符不是链式返回类型的解法
链式调用要求每一步方法都返回“当前构建器类型”，以便后续调用能继续访问子类特有方法。而通配符（如Builder<? extends Person>）表示一个未知的具体子类型，它不可作为返回类型参与方法链——编译器无法确认setName().setAge()后还能调用子类独有的setEmployeeId()。
- 通配符是只读友好（PECS原则中的“Consumer”侧），适合传入参数，不适合构建过程中的“Producer”链路
-
Builder<? extends Person>不能安全调用build()得到具体子类实例，更无法支持setEmployeeId()等子类方法 - 一旦方法返回含通配符的类型，链式就中断：IDE无法提示子类方法，编译器拒绝后续调用
真正有效的方案是泛型自引用（Self-Type）
让每个Builder方法返回精确的、调用者实际所属的子类Builder类型，核心是把泛型参数绑定到方法上，而非仅类声明：
- 基类Builder定义泛型方法：
<T extends Builder<T>> T name(String name) - 子类Builder继承时固定类型：
class EmployeeBuilder extends Builder<EmployeeBuilder> - 子类重写方法时仍返回
EmployeeBuilder，保证name("A").setEmployeeId(123)合法
Lombok多层继承时的实操处理
当使用@Builder遇到A → B → C继承链时，冲突源于builder()静态方法重名且返回类型不同。此时不用通配符，而是用命名隔离：
立即学习“Java免费学习笔记（深入）”；
- 父类保留
builder()，返回ABuilder - 子类B用
@Builder(builderMethodName = "bBuilder")，返回BBuilder - 子类C用
@Builder(builderMethodName = "cBuilder")，返回CBuilder - 调用时明确区分：
B.bBuilder().x(...).build()或C.cBuilder().y(...).build()
手动Builder中保持类型不丢失的关键写法
避免常见错误：不要在方法签名中写死返回原始类型（如public Builder setName(...)），而要让返回类型携带调用者真实类型：
- 错：
public Builder setName(String n) { this.name = n; return this; }→ 返回Builder，丢失子类信息 - 对：
public <T extends Builder<T>> T setName(String n) { this.name = n; return (T) this; }→ 类型推导出实际子类 - 更安全的变体（避免强制转型）：
protected abstract T self();，子类实现return (T) this;，各方法统一返回self()
