菲律宾梁朝伟你写代码这么多年，有没有遇到过这种对象：构造函数十几个参数、一半可以填一半可以不填、字段之间还有依赖关系，每次 new 的时候对着 IDE 的提示数半天参数顺序？我有段时间只要看到超过五个参数的构造方法就头疼，直到真正把建造者模式（Builder Pattern）用熟了，才发现之前很多"设计得太冗余"的类，其实换一种创建方式就能瞬间清爽。
这篇文章，我想把建造者模式从头到脚扯清楚。不止是理论上的"将一个复杂对象的构建与表示分离"，更重要的是：这个模式到底解决什么真实的研发痛点、写代码的时候怎么一步一步落地、有哪些必须踩过才知道的坑，以及为什么 StringBuilder、AlertDialog.Builder、Retrofit 这些你每天都在用的东西，骨子里全是它的影子。
如果你是正在准备设计模式期末、或者在做 Java 设计模式相关大作业，又或者已经在项目里写了不少业务代码但总觉得实体类创建很别扭，这篇文章应该刚好对你胃口。
1. 构造函数参数爆炸：Builder 到底在解决什么问题
1.1 从一个真实到让人头疼的订单类说起
很多教材讲设计模式喜欢一上来就画类图，但我觉得得先让你看到一个"没有用建造者模式时，代码会烂成什么样"的场景，你才能真正理解这个模式的价值。
假设你在写一个电商系统的订单实体。订单这个对象天生就复杂：订单号、用户 ID、商品列表、收货地址、优惠券信息、支付方式、配送时间、买家备注、卖家备注、发票信息……而且很多字段不是必填的。你很可能写出下面这种构造方法：
java复制public class Order {
private String orderId;
private long userId;
private List<Item> items;
private String shippingAddress;
private String couponId;
private String paymentMethod;
private Date deliveryTime;
private String buyerRemark;
private String sellerRemark;
private boolean needInvoice;
private String invoiceTitle;
public Order(String orderId, long userId, List<Item> items, String shippingAddress,
String couponId, String paymentMethod, Date deliveryTime,
String buyerRemark, String sellerRemark, boolean needInvoice,
String invoiceTitle) {
this.orderId = orderId;
this.userId = userId;
this.items = items;
this.shippingAddress = shippingAddress;
this.couponId = couponId;
this.paymentMethod = paymentMethod;
this.deliveryTime = deliveryTime;
this.buyerRemark = buyerRemark;
this.sellerRemark = sellerRemark;
this.needInvoice = needInvoice;
this.invoiceTitle = invoiceTitle;
}
}
这段代码有问题吗？语法上完全没问题，代码审查的时候也能通过。但等你真正去调用的时候，痛苦就来了。你在业务层创建订单，可能只想设置订单号、用户 ID、商品列表，其他全都用默认值。可是构造函数要求你把 11 个参数全部传进去，哪怕你传 null、传 0、传 false，你也得一个个占住位置。
更要命的是哪些字段是必填的，哪些是选填的，构造函数完全没法表达。你只能靠读代码、靠注释、靠同事口口相传去理解。要是哪天参数顺序调整了，或者中间插入一个参数，所有调用方全都编译报错。这种代码写多了，你会觉得每次创建对象都像在做一次小心翼翼的排雷。
1.2 为什么重载构造方法也是一种妥协
有人说，参数多那就重载呗，写几个精简版本的构造方法不就行了。听起来有道理，但你试过就知道，重载构造方法其实是另一种灾难。
比如你写一个 3 参数的构造方法（orderId, userId, items），再写一个 5 参数的（orderId, userId, items, shippingAddress, paymentMethod），再写一个 6 参数的……你会发现参数列表越来越长，而且经常出现类型相同、含义不同的参数。两个 String 类型的相邻参数，到底谁是谁，人脑根本记不住。调用的时候一不留神就把 couponId 和 buyerRemark 传反了，编译能过，运行结果错得莫名其妙。
JavaBean 的 setter 模式倒是能解决参数可读性的问题，先 new 一个空对象，然后一个一个 set。但这样会带来一个新的问题：一个对象的创建过程被强行切成了很多步，而且字段之间的约束关系很难保证。比如某些字段相互依赖，或者在对象刚创建出来的那一刻就必须处于合法状态，你用 setter 就很难控制。总不能在每一个 setter 里面校验别的字段是不是已经设置好了吧？那样逻辑会散得到处都是。
建造者模式走的是另一条路：把对象的构建过程封装到独立的 Builder 里面，用链式调用一步步设置参数，最后统一调用 build() 完成创建和校验。这样既保留了 setter 方式的清晰可读，又能在 build() 里面完成完整性校验和不可变对象的构建，可以说是兼顾了两种方案的长处。
1.3 Builder 模式的适用边界：什么情况下才值得用
需要说明的是，建造者模式并不是什么场景都用。如果有一天你去面试，面试官让你说说 Builder 的优缺点，你如果回答"它能让代码更好看"，那说明你还没有真正理解这个模式的适用边界。
从我个人的经验来看，建造者模式真正适用的场景有几个明确特征：首先是对象字段足够多，起码五六个以上，而且有不少选填项；其次是对象的创建过程有步骤、有顺序，或者字段之间存在依赖关系；最后是你希望对象创建出来之后就是完整的、不可变的，而不是先 new 出来再靠 setter 一点一点填。
反过来，如果类只有两三个必填字段，那你直接用 constructor 就行，甚至可以考虑用简单的静态工厂方法命名一下意图，比如 createDefaultUser()。硬生生套 Builder，反而会引入不必要的代码量，让简单的事情变复杂。很多初学者学完一个模式之后容易走火入魔，看到什么类都想给它配一个 Builder，这个毛病得戒。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 建造者模式的骨架拆解：四个角色的职责必须分清楚
2.1 Product、Builder、ConcreteBuilder、Director 的标准结构
如果你去翻经典的《设计模式》那本书，建造者模式的标准类图里有四个角色：Product（产品）、Builder（抽象建造者）、ConcreteBuilder（具体建造者）、Director（指挥者）。我在学习的时候最大的困惑是：这个 Director 到底有什么用？写代码的时候真的要定义一套这么完整的接口吗？
先把这个经典结构梳理清楚。Product 就是你要构建的那个复杂对象，比如订单、电脑、套餐。Builder 是一个接口（或者抽象类），里面定义了一系列构建部件的方法，比如 buildMainBoard()、buildCpu()、buildMemory()。ConcreteBuilder 是 Builder 接口的实现，具体实现每个部件的构建逻辑，同时它还得维护一个被构建产品的引用。Director 则负责编排构建顺序，决定先调哪个方法后调哪个方法。
在这套经典结构中，客户端不直接跟 ConcreteBuilder 打交道，而是告诉 Director "我要一个游戏本"，Director 就知道应该依次调用 buildCpu()、buildGpu()、buildScreen() 等一系列方法，最终从 Builder 那里 getResult() 拿到成品。
2.2 简化版的 Builder 才是日常开发最常用的形态
但是这个经典结构说实话，平时写业务代码很少会用得这么重。真正在项目里高频出现的是它的简化形态，也就是"产品内部嵌套一个静态 Builder 类"的形式，像 Lombok 的 @Builder 注解生成的代码就是这个思路。
在简化版中，不再有独立的 Director 和抽象 Builder，构建逻辑全部收敛在 Product 内部的静态 Builder 中。客户端通过 Product.builder() 拿到 Builder 实例，链式设置字段，最后调用 build() 得到产品。你去翻现在主流的 JSON 库、HTTP 客户端、ORM 框架的源码，绝大多数都是这种简化版。
我自己有个体会：学习设计模式，最好两个版本都看一眼。经典版本让你理解模式的本源和抽象意图，简化版本让你知道工程上怎么落地。只学经典版本可能到写代码时无从下手，只学简化版本则会让你对模式的认知浮于表面，换个场景就认不出来了。
2.3 建造者模式的核心：链式调用为什么非返回 this 不可
链式调用是 Builder 模式最外显的特征，也是让代码变得流畅的关键。很多人会问：为什么 builder.setName("张三") 之后还能接着 .setAge(18)？原因其实非常简单，因为每个 set 方法最后 return this;，返回的是当前 Builder 对象本身。
你每次调用一个方法后，拿到的是一个指向同一个 Builder 实例的引用，所以可以继续在这个引用上调用下一个方法。这本质上就是 Fluent Interface（流式接口）风格的一种体现，它把方法调用串成了一条流水线，让代码读起来就像在念一句话。比如：
java复制Order order = Order.builder()
.orderId("1001")
.userId(9527L)
.items(itemList)
.shippingAddress("北京市朝阳区xx大厦")
.build();
这种代码的好处是，中途哪个参数不想要了，直接删掉那一行就行，完全不需要费力去匹配位置。而且参数名本身就是自注释的，couponId 就是优惠券 ID，不可能和 buyerRemark 搞混。
当然，流式接口风格也让返回值不再是 void，有些同学刚接触会觉得有点不习惯。但用顺手之后你再回头看那种 new Order(...)、长参数列表的写法，真的会觉得是两种完全不同的编码体验。
3. 手写一个产品级的 Builder 实现：从字段到 build() 的完整考量
3.1 定义一个典型复杂对象：用电脑配置单来做示范
理论讲再多，不如直接写一个能跑的代码。我选电脑配置单这个场景来演示，因为电脑的硬件组成大家比较熟悉：CPU、主板、内存、显卡、硬盘、电源、机箱、散热器，而且很多配置项是可选的。
定义一个 Computer 类，建一个嵌套的静态 Builder。关键的设计决策有两个：第一是 Computer 的构造方法设为私有，确保外部只能通过 Builder 创建；第二是字段设计成 final，让对象一旦构建出来就不可变。
java复制public class Computer {
private final String cpu;
private final String mainBoard;
private final String memory;
private final String gpu;
private final String storage;
private final String powerSupply;
private final String caseType;
private final String cooler;
private Computer(Builder builder) {
this.cpu = builder.cpu;
this.mainBoard = builder.mainBoard;
this.memory = builder.memory;
this.gpu = builder.gpu;
this.storage = builder.storage;
this.powerSupply = builder.powerSupply;
this.caseType = builder.caseType;
this.cooler = builder.cooler;
}
public static Builder builder() {
return new Builder();
}
public static class Builder {
private String cpu;
private String mainBoard;
private String memory;
private String gpu;
private String storage;
private String powerSupply;
private String caseType;
private String cooler;
public Builder cpu(String cpu) {
this.cpu = cpu;
return this;
}
public Builder mainBoard(String mainBoard) {
this.mainBoard = mainBoard;
return this;
}
public Builder memory(String memory) {
this.memory = memory;
return this;
}
public Builder gpu(String gpu) {
this.gpu = gpu;
return this;
}
public Builder storage(String storage) {
this.storage = storage;
return this;
}
public Builder powerSupply(String powerSupply) {
this.powerSupply = powerSupply;
return this;
}
public Builder caseType(String caseType) {
this.caseType = caseType;
return this;
}
public Builder cooler(String cooler) {
this.cooler = cooler;
return this;
}
public Computer build() {
// 在 build 方法里做字段校验
if (cpu == null || cpu.isEmpty()) {
throw new IllegalArgumentException("CPU不能为空");
}
if (mainBoard == null || mainBoard.isEmpty()) {
throw new IllegalArgumentException("主板不能为空");
}
return new Computer(this);
}
}
}
3.2 为什么字段校验必须放在 build() 而不是每个 setter 里
我见过一些新手实现 Builder 时，喜欢在 cpu(String cpu) 这样的方法里面直接做校验，比如 CPU 字段不能为空，就在 setter 里判断。这样做看着很严谨，实际上很别扭：如果你依次构建了七个字段，最后一个字段校验失败，前面七个 setter 的工作就全都白做了，而且你无法在任何一个 setter 里面同时检查"CPU 和主板是否匹配"这种跨字段的业务规则。
正确的做法是把校验逻辑统一收敛在 build() 方法里。因为 build() 是整个构建流程的终点，所有字段都已经传入，这个时候做整体校验最合适。既能检查单个字段是否缺失，也能做跨字段的一致性检查，比如"选了水冷散热器就必须选对应规格的机箱"。同时，每个配置方法保持简单，只负责赋值和返回 this，职责单一，测试起来也容易。
再往后走一步，如果你的构建过程确实需要分阶段，比如"第一阶段配置基础硬件，第二阶段配置外设"，可以通过 build() 里设置状态位来实现，而不是靠拆分 setter。设计模式的核心还是服务于代码的清晰度，不是为了复杂而复杂。
3.3 客户端调用：从"参数地狱"到流水线组装
有了 Builder 之后，客户端创建 Computer 的代码就很直观了：
java复制Computer gamingPC = Computer.builder()
.cpu("Intel i9-13900K")
.mainBoard("Z790 AORUS")
.memory("32GB DDR5 6400MHz")
.gpu("RTX 4080 16GB")
.storage("2TB NVMe SSD")
.powerSupply("850W 全模组")
.caseType("中塔侧透机箱")
.cooler("360水冷")
.build();
Computer officePC = Computer.builder()
.cpu("Intel i5-13400")
.mainBoard("B760M")
.memory("16GB DDR4")
.storage("512GB SSD")
.powerSupply("450W")
.caseType("小机箱")
.build();
注意第二个例子，办公电脑没有配置 GPU，因为核显够用；也没有配独立水冷，因为 CPU 自带散热器。这在普通构造函数里是难以优雅表达的一个痛点：你用同一个构造方法创建两个"缺胳膊少腿"的配置，要么得写很多重载，要么得传很多 null。而 Builder 只需要不调用对应的方法就行了，语义清晰，一行废话没有。
用这套写法，代码审查的人也不再需要去数参数顺序了，扫一眼链条上的方法名就能看懂每种配置的差异。这就是 Builder 在可读性上的价值——它让代码本身变成了文档。
3.4 用 Kotlin 写 Builder：apply/also 让链式调用更顺滑
如果你在用 Kotlin 写后端或者 Android，建造者模式的实现还可以更顺滑。Kotlin 的 apply 和 also 作用域函数天然适合流式配置，你甚至可以保留 JavaBuilder 的写法，然后用 apply 包装一层：
kotlin复制val gamingPC = Computer.builder().apply {
cpu("AMD Ryzen 9 7950X")
mainBoard("X670E")
memory("64GB DDR5 6000MHz")
gpu("RX 7900 XTX")
storage("2TB PCIe 5.0 SSD")
}.build()
如果你还想更进一步，用 Kotlin 的具名参数和默认参数能力，Builder 在大多数业务场景下是可以不写的。但这里有一个天然的对比价值：如果你要构建的是属于别人的类、或者要通过反射/反序列化去构造对象，Kotlin 默认参数也无能为力，这时还是得老老实实写 Builder。所以我个人的观点是：Kotlin 默认参数 + 具名参数是 Kotlin 下的"第一选择"，Builder 是 Java 世界的"主力方案"，两者不冲突，同时掌握你才能在团队协作中灵活切换。
4. 源码里的建造者模式：原来你天天都在用它
4.1 StringBuilder：最容易被忽略的 Builder 标准范例
很多人在刚学 Java 的时候就用过 StringBuilder，但是很少有人意识到，这其实就是建造者模式最简单、最标准的一个应用。
StringBuilder 做的事情很简单：你不断调用 append() 往里追加字符串片段，最后由 toString() 输出完整的字符串。在这个过程中，append() 返回的都是 this，可以链式调用；toString() 则相当于 build()，产出一个完整的 String 对象。不同的是，StringBuilder 没有把 StringBuilder 和 String 拆成两个完全独立的类，而是让构建对象本身也是目标类型，这是 Builder 模式的一种变体。
理解了这一点，你再去看 StringBuffer（线程安全版本）它的 sync 修饰只是额外保证线程安全，模式骨架和 StringBuilder 一模一样。以后面试官再问你对 Builder 模式的了解，你可以顺嘴提一句"我在日常开发中最早接触的 StringBuilder 其实就是 Builder 模式的一个变体"，往往能让对方觉得你是真的把模式融入到了日常认知里，而不是背课本。
4.2 java.util.stream.Stream：流式 API 中的 Builder 影子
Java 8 引入 Stream 流式操之后，很多人喜欢用 Stream 写集合处理的流水线，但很少人注意 Stream.builder() 的设计。如果你需要手动往一个 Stream 里添加元素，可以这样写：
java复制Stream<String> stream = Stream.<String>builder()
.add("Java")
.add("Python")
.add("Go")
.build();
这里 add() 方法同样返回 this，支持链式调用，最后用 build() 产出不可变的 Stream 对象。和 StringBuilder 不同的是，Stream.Builder 是一个独立接口，实现类可以内部隐藏状态；而且 build() 一旦调用，就不能再继续添加元素了，否则会抛异常。
这引出了 Builder 模式一个值得注意的细节：builder 和 product 的生命周期需要明确区分。java.util.stream 是直接告诉你"build 之后 builder 就作废了"。你在自己设计 Builder 的时候，也应该考虑这个问题。是想让 Builder 可复用（比如建造多个相似对象），还是 build 之后一次性作废？不同的选择，代码行为和边界条件会完全不同。
4.3 Android 的 AlertDialog.Builder 与 Retrofit：框架级 Builder 的现实价值
Android 开发者对 AlertDialog.Builder 一定不会陌生：
java复制AlertDialog dialog = new AlertDialog.Builder(context)
.setTitle("提示")
.setMessage("确定要删除这条记录吗？")
.setPositiveButton("确定", listener)
.setNegativeButton("取消", null)
.create();
AlertDialog 的构造方法是私有的，外部只能通过 Builder 来创建。我在早期写 Android 的时候，第一反应是"为什么要这么麻烦，直接 new 一个 AlertDialog 然后 setTitle、setMessage 不就行了"？等后来见过很多因为忘调 create() 导致的崩溃，才体会到 Builder 模式在这里的价值：它强制你一次性把关键参数准备齐，并且让 AlertDialog 对象从创建那一刻就处于可用状态，而不是留下一个半初始化对象。
再来看 Retrofit。你用 Retrofit 创建网络请求实例，基本上都会经历一大段链式配置：
code复制Retrofit retrofit = new Retrofit.Builder()
.baseUrl("https://api.example.com/")
.addConverterFactory(GsonConverterFactory.create())
.client(okHttpClient)
.build();
Retrofit 需要配置的东西很多：baseUrl、ConverterFactory、CallAdapterFactory、OkHttpClient 等等，而且这些配置之间存在依赖关系。比如你配了某种 Converter，就得配对应的 CallAdapter，这种关联约束在 build() 方法里被集中校验，一旦配置非法直接快速失败。这就是 Builder 模式在框架设计中的典型好处：屏蔽复杂的初始化流程，对外暴露简单直观的入口。
4.4 Apache Commons / Lombok @Builder：别再造重复轮子
如果你查 Java 的经典开源库，会发现很多都有 Builder 的影子。比如 Apache Commons Lang3 的 Range<T>、RandomStringUtils 的一些配置，再比如 Spring 框架里 UriComponentsBuilder，都是 Builder 模式在各领域的应用。这些库的 Builder 形态略有不同，但核心思路都一样。
那有人会问：我项目里的类很多，是不是要自己写一堆 Builder？答案是有更省事的方式——Lombok 的 @Builder 注解。给实体类加一个 @Builder，Lombok 会在编译期自动生成 Builder 内部类和对应方法。也就是说你不需要手写那些重复的链式方法了。这在字段特别多又比较固定的实体类上效率极高，是 Java 工程中非常受欢迎的一种提升效率的方式。
我自己会这样权衡：如果是核心领域模型、有复杂的校验逻辑或字段间约束，手写 Builder 更清晰，因为校验逻辑可以写得仪式感强一些；如果只是 DTO、VO、配置类等传输对象，直接上 Lombok @Builder 就好，节省时间还减少模板代码。
5. 建造者模式与工厂模式：看起来都是创建对象，区别在哪儿
5.1 两种模式的目标维度完全不同
设计模式里面，建造者和工厂都属于创建型模式，而且都能把"new"的过程封装起来。所以经常有同学搞混：有了工厂模式，为什么还需要建造者模式？或者反过来问，有了建造者模式，工厂模式是不是多余了？
核心区别在于：工厂模式解决的是"创建哪个对象的问题"，把对象的选择和客户端解耦。比如 ShapeFactory 会根据传入的枚举返回圆形、矩形还是三角形，它关心的是类型分发的逻辑。而建造者模式解决的是"如何一步步构建一个复杂对象的问题"，它关注的是组装的过程、参数的完整性、部件的顺序和组合规则。
你可以这样对比：工厂模式像是去饭店点菜，你说"来一份招牌菜"，厨房帮你选好并端上来，你完全不关心过程；建造者模式像是自己选食材一步步做菜，你可以精确控制每一步放什么、放多少，最后得到符合自己口味的菜肴。一个是黑盒，一个白盒，两者解决问题的角度完全不同。
5.2 实际项目中怎么组合使用
这里有一个在实践中经常用到的技巧：同时组合使用两种模式。比如有一个 ComputerFactory，它内部持有 Computer.Builder，然后工厂的方法只需要传入一个枚举（游戏本、办公本、设计本），工厂内部自己决定 Builder 如何配置：
java复制public class ComputerFactory {
public Computer createComputer(ComputerType type) {
Computer.Builder builder = Computer.builder();
if (type == ComputerType.GAMING) {
builder.cpu("i9").gpu("RTX 4080").memory("32GB");
} else if (type == ComputerType.OFFICE) {
builder.cpu("i5").memory("16GB");
}
return builder.build();
}
}
这种写法的优势很明显：客户端只需要知道我要一个游戏本，至于游戏本应该配什么硬件，那是工厂的事；同时，复杂对象的组装细节通过 Builder 被牢牢约束在工厂内部。这在框架设计中特别常见，既利用了工厂的类型封装能力，又利用了 Builder 的参数组装能力。
5.3 单例、原型等其他创建型模式与 Builder 的取舍
如果说类和类之间还有创建型的"竞争者"，那主要是单例和原型。单例模式关注"全局只有一个实例"，和 Builder 的关注点南辕北辙，一般来说不会冲突，除非你要构建一个全局唯一且参数复杂的配置对象，两者会有一些交集，比如 Spring 中复杂 Bean 的创建，既有单例容器，也有类似 Builder 的属性注入过程。
原型模式关注"通过复制已有对象来创建新对象"，适合创建成本高、需要保持状态的场景；Builder 则适合从零开始一步步构建。如果你的对象已经存在，想快速获得一个相似版本，原型更快；如果你的对象需要精细控制每一步，Builder 更合适。了解这些横向对比，能让你的设计模式知识不是孤立的"招式列表"，而是一套能互相组合的"工具箱"。这也是我在学习过程中比较受益的一种学习方法：不要孤立理解模式，而是把模式放到一起对比、组合、权衡。
6. 实战中的反模式与注意事项：用错 Builder 比不用更糟
6.1 所有字段全部必填却硬套 Builder
有一种常见的过度设计，就是明明只有三个必填字段，且没有任何可选项，也要给这个类写一个完整的 Builder。最后效果是代码量翻了三倍，每个字段都有两套重复的赋值路径，读者还得在 constructor 和 builder 之间来回切换，反而增加了认知负担。
对于这种对象，直接构造函数才是最清晰的选择。Java 允许同名不同参数的构造方法，配合静态工厂方法的命名描述意图，已经足够解决大部分简单场景。Builder 是一项宝贵的工具，但也像菜刀一样，不该用来削铅笔。你可以给自己定一个简单的规则：字段数量超过四个、或者存在多个可选项、或者构建过程有校验逻辑时，才优先考虑 Builder。
6.2 Builder 字段与产品字段不一致导致的隐性问题
在实际写 Builder 的时候，有一种潜在风险很隐蔽：Builder 里的字段和 Product 里的字段可能因维护不同步而产生偏差。字段不在一个类里，整理展开、编译不会提示，就会在运行期抛错。
我之前维护过一个老项目，Builder 里的字段有 12 个，产品类里有 13 个，因为迭代过程中某个字段被广告删除了但 Builder 里的赋值逻辑漏掉了，结果线上创建出来的对象永远少一个属性。这类坑靠 Code Review 不一定能查出来，最有效的办法是加测试：用 Builder 创建对象后，逐一断言所有字段都正确传递；也可以在建类的构造函数里将「Builder 中读取每个字段」的逻辑写全，最后编译期无法提醒，但测试能覆盖到。
如果你用 Lombok @Builder，本质上是由 annotation processor 在编译期自动生成 Builder，它从注解所注解类的字段中直接读取，因此字段同步的整体风险比手写 Builder 要低很多。这也是我建议传输对象能上用 Lombok 就尽量用 Lombok 的原因之一。
6.3 构建过程出现运行时异常时的错误信息设计
Builder 在 build() 里面做校验是好事，但如果校验失败时只抛一个模糊的 IllegalArgumentException("无效参数")，那排错体验会非常糟糕。尤其当一个类有十几个字段时，你根本不知道哪个字段出了问题。
我自己的习惯是，在 build() 校验中尽量把失败原因写得具体："Computer CPU 不能为空，请检查 Builder 配置"、"电源功率与显卡功耗不匹配，请调整电源配置"。Spring 的 IllegalArgumentException、Google 的 Preconditions.checkArgument 都支持带有模板参数的错误消息。把自己的错误信息写得足够清晰，虽然看似只是小细节，但在排查线上的神秘报错时，真的能省下大量时间。
6.4 通过注解处理器自动生成 Builder：Lombok 的局限与替代
Lombok 是很好用，但也不是没有局限。首先它在某些严格的企业环境里需要额外的编译配置和 IDE 插件支持；其次它生成了代码，很多人 debug 时进不去，会有点别扭；而且 Lombok 用的是编译期注解处理，如果你用了模块化系统或者某些对字节码敏感的场景，有时会遇到预设之外的坑。
替代方案也有几个：一个是 @Builder 加上 @NoArgsConstructor、@AllArgsConstructor、@Data 等组合；另一个是用 Kotlin 的 data class + 默认参数替代；还有一种是录制 record，本身不可变，加上 @Builder 或自定义静态工厂方法也可以。我的建议是：团队统一选一个方案作为规范，不要有的类用 Lombok Builder，有的类手写 Builder，有的类用静态工厂，否则项目维护起来会非常精神分裂。
6.5 继承体系中的 Builder 该怎么设计
当你碰到一个需要继承的类体系时，比如 BaseAnimal 和 Dog，建造者模式的实现会开始变得棘手。如果直接在 Dog 的 Builder 里写 new Dog(this)，你会发现 Dog 子类的 Builder 无法复用父类 Builder 构建好的字段。
一个常见的解法是让子类的 Builder 继承父类的 Builder，并在子类 Builder 里做类型转换（self 类型），支持链式调用仍返回子类 Builder 类型。这一步实现起来会比较绕，不少新手在这里卡住。
另一种更简单的方案是：不去让 Builder 继承，而是让子类 Builder 作为父类 Builder 的"包装器"，内部有一个父类 Builder 实例，逐个把父类字段搬过来。这样代码多一些，但思想直接，不容易出错。
如果你在写一个深度继承的类层次，我会建议重新审视类设计——过深的继承本身就可能是个坏味道，考虑组合优先或接口提取是不是更合理。
7. 期末考试与大作业视角：建造者模式怎么答才能拿高分
7.1 高频考点与回答框架
考虑到很多读者搜到这篇文章，是因为要准备设计模式期末或者 Java 设计模式相关的大作业，我顺带讲一下应试和作业这个视角下的重点。
考试中关于建造者模式的高频考点集中在：一是让画类图；二是让写一个示意性的代码；三是让解释与工厂模式的区别；四是给一个复杂对象创建场景，让你选合适的模式。回答这类题目时，我建议按照这样的框架组织答案：先讲痛点（参数过多导致构造方法可读性差、可维护性差、约束难表达）；再讲解决方案（Builder 模式将构建过程与产品本身分离，通过链式调用分段配置，最终在 build() 中校验并生成不可变对象）；最后讲适用性和局限（字段多、有可选参数、创建过程有步骤时适用；参数少时反而增加复杂度）。
这样一块答题，通常能让判卷老师感受到你不仅记住了定义，而且具备实际应用的分析能力，分数一般不会低。
7.2 大作业常用场景与代码结构建议
如果是设计模式大作业，选择一个容易被理解又有一定复杂度的场景非常关键。比较经典的包括：电脑组装、手机定制、手机商品套餐、披萨定制、旅游套餐，或者订单创建。这些场景的共同点是：字段多、可选配置多、过程有顺序、结果物直观，用例子来讲解很容易让读者产生代入感。
作业代码建议按包结构组织：entity（产品）、builder（抽象或静态建造者）、director（如果有的话）、client（演示调用）。这样整体结构非常像教材上的标准样式。同时记得在 README 中写清楚：为什么用 Builder 不用工厂、代码运行效果如何、每个角色对应图中哪个部分。把代码和模式理论一一对应，作业的完整性就能上一档。
如果做成演示项目，还可以考虑把 Builder 和 Strategy、Factory 结合展示，体现模式之间的组合运用。能在作业里适度展示"多种模式的组合"，会是一个不错的加分项。
7.3 面试中如何把这个话题聊出深度
如果你是在准备面试，那建造者模式的话题自由度更大。面试官可能会问"你在哪个项目中使用过 Builder 模式"、"Builder 解决过什么实际问题"。我的建议是不要简单回答"我在实体类上加了 @Builder"，而是讲清楚当时遇到的具体场景：比如订单模型有十几个字段、创建时业务上需要区分场景、有的字段不填就会走错状态，所以为了解决"构造方法参数过长、可读性差、不可变对象难以保证"这几个问题选了 Builder。
如果在面试中能把 StringBuilder、Stream.builder()、Retrofit.Builder 作为例子信手拈来，并且能说出"build() 之后 builder 作废"、"校验集中放在 build()" 这些细节，面试官对你的代码感和设计意识印象会非常深刻。记住，设计模式的面试考察的是你是否真的在实际项目中解决过问题，而不是背上多少定义。
8. 我踩过的建造者模式的坑：一些真实的小教训
最后分享几个我这些年实际使用 Builder 过程中积累的小教训，每个都是真金白银换来的。
第一个是，Builder 的链式调用并不是线程安全的。如果你在一个多线程环境里共享同一个 Builder 实例，并且多个线程同时在调用配置方法，最后 build() 出来的对象很可能缺漏字段。Java 的 Stream.builder() 文档就明确说过它不是线程安全的。解决方案是每次创建新的 Builder 实例，或者加同步，或者干脆把 Builder 设计成不可变风格（每次 set 返回新的 Builder）。团队协作中这种问题特别隐蔽，因为它不会稳定复现，往往压测的时候才暴露。
第二个是，不要为了让 Builder 看起来很强就把校验塞到 build() 以外的任何地方。所有的校验逻辑集中一个地方是维护方最开心的结构。你分散在多个 setter 里的校验会让人很难弄清"哪些参数在什么时候已经生效了"，一旦后续需求调整，改起来非常痛苦。
第三个是，小心 Lombok @Builder 与 JSON 反序列化的组合问题。有些 JSON 反序列化框架（如 Jackson）默认优先使用无参构造器和 setter，或者根据参数名匹配构造器；当你只加了 @Builder 而没有提供其他反序列化路径时，某些情况下反序列化会失败或者出现默认值。这种问题往往只在线上数据回读时爆发，你本地单元测试根本测不出来。解决方案一般是配合 @NoArgsConstructor、@AllArgsConstructor 或者 @JsonPOJOBuilder 去适配。多写一个注解不算事，但在线上排查的时间可真不少。
第四个是，Builder 的字段默认值要小心。因为 Bob the Builder 和 Product 同时存在默认值时，容易产生歧义：Bob the Builder 初始化为空，最后 build() 时赋给的域默认值生效，但如果产品字段本身就是 null，用户未必分得清是"没设置"还是"设置为 null"。最好的做法是：在 Bob the Builder 里明确标注哪些字段有业务默认值，并把这些默认值写在 build() 里，而不是分散到每个 setter 中。这样你一眼就能看出构建结果的最终字段情况。
这些坑可能并不是你在入门时立刻会遇到的，但真正走进大规模项目、和团队成员协作时，每一个都可能变成线上事故或至少是排障时间的大幅拉长。提前知道这些，能让你在设计阶段就提前规避，而不是等出了问题再反向修补。