Golang建造者模式详解与实例应用

Go中需用建造者模式解决字段组合爆炸、创建逻辑外泄、测试构造困难三类问题；应设计为值类型、链式返回新副本、Build()封装校验，避免指针修改与过度泛型。

为什么 Go 里直接用结构体字面量就够了，还要搞建造者模式？

Go 没有构造函数重载，也没有可选参数语法，当一个结构体字段多、部分字段有默认值、某些字段需校验或依赖其他字段时，struct{} 字面量会迅速变得难读、易错、不可复用。建造者模式不是为了“炫技”，而是为了解决：字段组合爆炸、创建逻辑外泄、测试时构造脏数据困难这三类实际问题。

比如你要建一个 HTTPClient，要支持设置超时、代理、TLS 配置、重试策略、日志钩子……全塞进一个 newHTTPClient() 函数里，调用方根本记不住参数顺序；而全用字段赋值又没法做前置校验（比如 Timeout 不能 ≤ 0）。

如何写一个符合 Go 习惯的建造者（非泛型版）

关键点是：把 builder 设计成值类型、链式调用返回新副本、最终用 Build() 封装校验和对象组装。不暴露未完成状态，避免误用。

常见错误是让 builder 持有指针并原地修改——这会导致并发不安全，也违背 builder “不可变中间态” 的本意。

• Builder 类型定义为普通 struct，字段与目标对象一致或更宽（比如加 err error 记录校验失败）
• 每个 setter 方法签名统一为 func(b Builder) Builder，内部用 return b 返回新值
• Build() 方法做终局校验，校验失败时返回 (Target, error)，不 panic
• 不要导出 builder 的字段，只通过方法控制访问

示例：

type User struct {
    Name  string
    Age   int
    Email string
}

type UserBuilder struct {
    name  string
    age   int
    email string
    err   error
}

func NewUserBuilder() UserBuilder { return UserBuilder{} }

func (b UserBuilder) Name(n string) UserBuilder {
    if n == "" {
        b.err = fmt.Errorf("name cannot be empty")
    }
    b.name = n
    return b
}

func (b UserBuilder) Age(a int) UserBuilder {
    if a < 0 || a > 150 {
        b.err = fmt.Errorf("age must be between 0 and 150")
    }
    b.age = a
    return b
}

func (b UserBuilder) Email(e string) UserBuilder {
    if !strings.Contains(e, "@") {
        b.err = fmt.Errorf("invalid email format")
    }
    b.email = e
    return b
}

func (b UserBuilder) Build() (User, error) {
    if b.err != nil {
        return User{}, b.err
    }
    return User{Name: b.name, Age: b.age, Email: b.email}, nil
}

什么时候该用泛型建造者？怎么避免过度设计？

当你发现多个 struct 共享相似构建逻辑（比如都有 Name、ID、CreatedAt），且这些字段初始化方式高度一致时，才值得抽象泛型 builder。但 Go 泛型在 builder 场景下容易失控：类型约束难写、错误信息晦涩、IDE 支持弱。

更务实的做法是：先为每个关键 struct 写独立 builder；等出现 3 个以上重复逻辑（如校验邮箱、生成 UUID、设置默认时间），再抽一个 BaseBuilder[T any]，只封装通用字段和校验，不试图覆盖全部行为。

• 泛型 builder 的 Build() 必须返回 (T, error)，不能省略 error —— 否则校验失败时无法反馈
• 避免在泛型 builder 中嵌入业务逻辑（如“自动补全 domain”），那属于具体 builder 的职责
• 如果某个 struct 的构建过程涉及外部调用（如查数据库、发 HTTP 请求），别放进 builder；那是 factory 或 service 层的事

builder 和 struct embedding、functional options 怎么选？

Functional options（函数式选项）是 Go 社区更主流的选择，尤其适合配置类对象（如 http.Client）。它轻量、无状态、易组合。但它的缺点也很明显：无法做字段间依赖校验（比如“设置了 RetryPolicy 就必须设 MaxRetries”），也不方便分阶段构造（比如先设基础信息，再根据条件追加扩展字段）。

Struct embedding（内嵌 builder）本质是把 builder 当作匿名字段混入目标 struct，破坏封装性，且无法控制字段赋值顺序和时机，已基本被弃用。

结论：优先用 functional options；只有当你需要跨字段校验、分步构造、或 builder 本身要复用多次（如批量创建不同变体）时，才上完整 builder。

容易被忽略的一点：无论选哪种，都别让 builder 成为“万能构造入口”。如果一个 builder 的 Build() 方法里开始做 I/O、加锁、或调用其他服务，说明它已经越界了——那不是 builder，是 factory，该拆出去。