Go中需用建造者模式解决字段组合爆炸、创建逻辑外泄、测试构造困难三类问题；应设计为值类型、链式返回新副本、Build()封装校验，避免指针修改与过度泛型。
为什么 Go 里直接用结构体字面量就够了，还要搞建造者模式？
Go 没有构造函数重载，也没有可选参数语法，当一个结构体字段多、部分字段有默认值、某些字段需校验或依赖其他字段时，struct{} 字面量会迅速变得难读、易错、不可复用。建造者模式不是为了“炫技”，而是为了解决：字段组合爆炸、创建逻辑外泄、测试时构造脏数据困难这三类实际问题。
比如你要建一个 HTTPClient，要支持设置超时、代理、TLS 配置、重试策略、日志钩子……全塞进一个 newHTTPClient() 函数里，调用方根本记不住参数顺序；而全用字段赋值又没法做前置校验（比如 Timeout 不能 ≤ 0）。
如何写一个符合 Go 习惯的建造者（非泛型版）
关键点是：把 builder 设计成值类型、链式调用返回新副本、最终用 Build() 封装校验和对象组装。不暴露未完成状态，避免误用。
常见错误是让 builder 持有指针并原地修改——这会导致并发不安全，也违背 builder “不可变中间态” 的本意。
立即学习“go语言免费学习笔记（深入）”；
-
Builder类型定义为普通 struct，字段与目标对象一致或更宽（比如加err error记录校验失败） - 每个 setter 方法签名统一为
func(b Builder) Builder，内部用return b返回新值 -
Build()方法做终局校验，校验失败时返回(Target, error)，不 panic - 不要导出 builder 的字段，只通过方法控制访问
示例：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
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，该拆出去。
