这确实是一种不可变对象的流畅构建方案，完全可以作为Builder模式的替代选项，咱们从几个核心维度拆解分析：

核心特性匹配度 #

• 不可变性保障：每次调用x(String x)或y(String y)都会创建全新的Config实例，原实例的属性不会被修改，完美符合不可变对象的设计要求，天然线程安全。
• 流畅API体验：支持链式调用（比如Config.create().x("foo").y("bar")），和Builder模式的调用风格完全一致，可读性拉满。
• 无额外Builder类：直接复用目标类Config自身完成构建逻辑，完全满足你不想额外创建Builder类的需求，代码更精简。

内存与性能影响 #

• 内存开销：每次修改属性都会生成新的实例，如果构建过程中存在多次连续修改（比如create().x("v1").x("v2").y("v3")），会产生多个短期存活的中间对象。不过不用太担心——现代JVM的垃圾回收机制对这类小对象的回收效率极高，在绝大多数业务场景下（比如配置类构建），这种开销完全可以忽略。
• 性能对比：和传统Builder模式相比，Builder是在同一个临时实例上修改属性，最后一次性生成不可变对象，不会产生中间实例。但这种性能差异只有在极端频繁构建+多次属性修改的场景下才会显现，普通业务场景下根本感知不到区别。

方案的优缺点 #

优点 #

• 代码结构简洁，不需要维护额外的Builder类，减少项目类数量
• 天然不可变，避免了并发场景下的线程安全问题
• 调用方式和Builder一致，学习成本低

缺点 #

• 新增属性时，每个现有的属性修改方法都要同步更新（复制所有属性），扩展性不如Builder模式（Builder只需要新增一个setter方法，build时统一复制）
• 极端场景下的中间实例可能带来微小的GC压力

适用场景 #

这种方案特别适合：

• 属性数量不多（比如3-5个）的不可变对象
• 构建过程中属性修改次数较少的场景
• 希望保持代码精简，不想引入额外Builder类的场景

内容的提问来源于stack exchange，提问作者Julez