建造者模式适用于字段多、可选字段多、需默认值管理、统一校验及不可变性的复杂对象构建。它通过链式调用提升可读性，延迟校验至Build()阶段，支持不可变对象创建与子类型复用，但简单对象无需使用。
构造参数多、可选字段多的对象
当一个结构体有 5 个以上字段，其中 2–3 个是可选的（比如 ServerConfig 的 CertFile、EnableTLS、Middlewares），直接用结构体字面量初始化会频繁出现零值或 nil 占位，阅读和维护困难。建造者模式把字段设置拆成链式方法调用，让意图一目了然。
- 避免“伸缩构造函数”（telescoping constructor）：Go 不支持重载，没法像 Java 那样写多个
NewXxx()变体 - 不用反复写
&ServerConfig{Host: "x", Port: 8080, ...}这类易错长表达式 - 默认值集中管理（如
Port: 8080、ReadTimeout: 5 * time.Second）放在NewServerConfigBuilder()里，而非散落在各处
需要在构建完成前做统一校验
有些字段之间存在约束关系，比如 EnableTLS == true 时必须提供 CertFile 和 KeyFile；又或者端口必须在 1–65535 范围内。这些逻辑不适合塞进每个 setter 方法里，而应延迟到 Build() 阶段一次性检查。
-
Build()是唯一出口，天然适合集中做参数合法性校验 - 校验失败可 panic、返回 error 或返回
(*T, error)，比构造后才发现问题更早暴露 - 避免构造出半残缺对象（例如
Port: 0却没被发现，直到运行时报错）
希望对象实例不可变（immutable）
很多配置类对象一旦创建就不该被修改（比如 HTTP server 启动后
禁止动态改 Host）。建造者模式天然支持“构建即冻结”——Build() 返回的是只读副本或不暴露字段的结构体指针，外部无法再修改内部状态。
- 字段全部小写（未导出），只通过 builder 提供受控的设置入口
- 如果需要真正不可变，
Build()应返回深拷贝（尤其含切片、map、指针字段时） - 注意：若 builder 内部直接返回
b.config（如示例中那样），则外部仍可能通过引用修改原值，这是常见疏漏
要复用构建流程生成不同子类型
当需要基于同一套步骤（如“设置主机→设端口→加中间件→启用安全”）但产出不同具体类型（*HTTPServerConfig / *GRPCServerConfig），可以抽象出 Builder 接口，由不同 concrete builder 实现细节。
- Director 角色（可选）能封装通用流程，比如
SetupCommonSteps(b Builder) - 适合 SDK 设计：用户调用相同链式 API，底层根据选项返回不同协议的配置对象
- 但纯 Go 中接口抽象会增加样板，简单场景直接用具体 builder 更轻量
建造者模式不是银弹。字段少、无默认值、无校验需求的对象（比如只有 Name 和 ID 的 User）硬套 builder 反而啰嗦。关键在“复杂性是否真的存在”——参数爆炸、校验耦合、不可变诉求，三者占其一，就值得引入。
