Builder 模式在 Go 中通过指针接收者实现链式调用，所有构建方法必须为 Builder 接收者并返回 Builder，Build() 返回目标对象并校验必填字段；适用于字段多、有依赖或需运行时校验的场景，非线程安全且不可复用。
Builder 模式在 Go 里不是靠继承，而是靠返回 *Builder 实例链式调用
Go 没有构造函数重载，也没有 this 指针自动返回，所以 Builder 的“链式”必须显式返回指针。常见错误是写成值接收者方法，导致每次调用都操作副本，字段根本没变。
- 所有构建方法必须是
*Builder指针接收者，返回*Builder - 不要用值接收者（
func (b Builder) WithName(...)），那只是改了临时副本 - 最终
Build()方法应返回目标对象（如*User），且通常做必要校验（比如必填字段是否为空）
示例关键片段：
func (b *UserBuilder) WithName(name string) *UserBuilder {
b.name = name
return b // 必须返回 b，不是 new(UserBuilder)
}
func (b *UserBuilder) Build() (*User, error) {
if b.name == "" {
return nil, errors.New("name is required")
}
return &User{name: b.name, age: b.age}, nil
}
为什么不用结构体字面量直接初始化，而要 Builder？
当对象字段多、存在可选/互斥/依赖关系，或构造逻辑需复用时，字面量初始化会迅速失控。比如 API 客户端配置：TLS 设置和跳过验证不能共存，超时默认值需根据环境调整——这些逻辑塞进调用方，会污染业务代码。
- 字段超过 4–5 个且含可选项，Builder 可读性明显提升
- 需要运行时校验（如 URL 格式、端口范围）时，Builder 的
Build()是天然校验入口 - 不同场景复用同一 Builder：测试用内存版 DB 客户端、生产用连接池版，只需换掉部分
WithXXX()调用
反例：硬编码字段顺序的结构体字面量 User{Name: "a", Age: 0, Email: "", Active: true, CreatedAt: time.Now()} —— 新增字段就得改所有调用点。
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
Builder 和 Option 模式怎么选？
两者都能解决可选参数问题，但语义和约束力不同。Option 更轻量，适合纯配置；Builder 更重，适合带状态、需校验、或多阶段构造的场景。
- 用
Option：HTTP 客户端超时、重试次数、User-Agent 字符串等独立、无依赖的配置项 - 用
Builder：数据库连接字符串解析后需验证 host/port、组合 TLS 配置、生成 DSN —— 这些步骤有先后、有副作用、需集中校验 - 性能上差异极小，但 Builder 多一次 struct 分配；Option 组合时若传入大量闭包，可能影响内联
别强行统一：一个项目里 DBBuilder 做连接构造，HTTPOption 控制请求行为，完全合理。
容易被忽略的坑：Builder 不是线程安全的，且生命周期需明确
Builder 实例内部保存中间状态，如果多个 goroutine 并发调用它的方法，字段会被覆盖。更隐蔽的问题是，Builder 持有对最终对象字段的引用（比如切片、map），若 Build 后继续修改 Builder 字段，可能意外污染已构造对象。
- Builder 实例不要复用：每次构造新对象前，都要
new(UserBuilder)或调用工厂函数 - 避免在
Build()后继续调用WithName()等方法 —— Go 不报错，但语义已失效 - 如果 Builder 内部缓存了 map/slice，
Build()返回前务必深拷贝，否则外部修改会影响已返回对象
最简单的防御方式：把 Builder 设为不可导出（首字母小写），只暴露工厂函数 NewUserBuilder()，并在文档里写明“Builder 实例不可复用”。
