建造者模式适合创建复杂对象，但仅当构造参数多、可选配置多且需分步控制时才真正必要；若不满足不变量校验、组合差异大等条件，应优先使用带默认值的New函数。
建造者模式真适合创建复杂对象吗
适合，但前提是“复杂”体现在构造参数多、可选配置多、创建逻辑需分步控制——不是所有字段多的结构体都值得上建造者。Go 语言没有构造函数重载和默认参数，struct 初始化时若字段超过 4–5 个且存在多种组合，硬写 &MyStruct{A: x, B: y, ...} 就容易出错、难维护、无法表达意图。这时候建造者才真正有用。
什么场景下该用 builder 而不是简单 New 函数
看这几点是否同时满足：
- 对象必须满足某些不变量（比如
URL字段不能为空，Timeout必须 > 0），而这些校验不能推迟到运行时才做 - 有多个可选配置项，且不同业务路径启用的组合差异大（比如 HTTP 客户端要支持自定义
Transport、Timeout、RetryPolicy，但 A 服务只设超时，B 服务只换 Transport） - 创建过程需要分阶段验证或组装（比如先设置基础地址，再添加中间件，最后冻结不可变）
- 你希望隐藏内部字段细节，对外只暴露“有意义的构建动作”，比如
WithTimeout()比直接赋值timeout: 30 * time.Second更语义化
不满足以上任何一条，就别强行套 builder——一个带默认值的 NewXxx() 函数 + 一两个 WithXXX 方法更轻量。
builder 实现中三个最容易踩的坑
Go 的 builder 常见写法是返回 *Builder 自身实现链式调用，但实际落地时这几个点常被忽略：
立即学习“go语言免费学习笔记（深入）”；
- builder 方法不应该修改已构建好的字段：如果
b.url已设，再次调用b.WithURL()应该 panic 或返回 error，否则使用者无法感知误操作 - 最终
Build()方法必须做完整校验，而不是把校验分散在每个 WithXXX 里；否则可能漏掉组合约束（比如WithRetryPolicy()和WithMaxRetries(0)冲突） - 不要让 builder 持有未导出的私有字段指针（如
url *string），否则用户传入的变量生命周期可能影响 builder 行为；应该拷贝值，或明确文档说明所有权转移
type ClientBuilder struct {
url string
timeout time.Duration
retry bool
}
func (b ClientBuilder) WithURL(u string) ClientBuilder {
if u == "" {
panic("URL cannot be empty")
}
b.url = u
return b
}
func (b ClientBuilder) Build() (HTTPClient, error) {
if b.url == "" {
return nil, fmt.Errorf("URL required")
}
if b.timeout <= 0 {
b.timeout = 30 * time.Second
}
return &HTTPClient{url: b.url, timeout: b.timeout, retry: b.retry}, nil
}
builder 和 functional options 怎么选
Functional options（函数式选项）更轻、更灵活，适合配置项少、组合简单、不需要强制顺序或阶段校验的场景；builder 更重，但能封装状态、提供清晰的构建流程、天然支持分步验证。两者不是互斥的：
- 可以先用 functional options 实现
NewClient(WithURL("..."), WithTimeout(...)) - 当发现 options 组合开始出现“必须配对”（比如
WithTLSConfig()隐含要求WithScheme("https")），就该考虑升级成 builder - 也可以混用：builder 内部用 functional options 管理某类配置（如日志选项），避免 builder 方法爆炸
真正麻烦的不是选哪个，而是过早抽象——先写死几个 New 函数，等第三个业务方提出“我只要改超时和重试次数”，再抽 builder 不迟。很多 Go 项目里的 builder，其实只是把 New 函数拆成了四行链式调用而已。
