Go中Builder模式不用class和new，因其无构造函数重载、继承和new关键字；改用函数式组合与未导出字段控制可见性，通过链式方法返回指针、Build()校验并创建不可变对象。
Builder 模式在 Go 里为什么不用 class 和 new
Go 没有构造函数重载、没有继承、也没有 new 关键字，所以传统 OOP 中的 Builder 模式（比如 Java 里嵌套静态类 + 链式调用）不能直接照搬。强行模仿反而会让代码臃肿、接口不自然。
Go 更倾向用「函数式组合」和「结构体字段控制可见性」来实现 Builder：把构建逻辑拆成普通方法，返回指针自身以支持链式调用；用未导出字段（小写首字母）防止外部直接赋值。
-
Builder通常是一个导出结构体，但内部状态字段不导出（如name string而非Name string） - 每个设置方法（如
WithName()）返回*Builder，便于链式调用 -
Build()方法做最终校验并返回目标对象——它应是不可变的、导出的结构体 - 避免在
Build()中做耗时操作（如网络请求），否则违背 Builder 的“纯构建”语义
一个实用的 HTTP 客户端 Builder 示例
比如封装 http.Client 构建过程，常见需求包括设置超时、自定义 Transport、添加默认 Header。直接传一堆参数易错且难维护。
type HTTPClientBuilder struct {
timeout time.Duration
transport *http.Transport
headers map[string]string
}
func NewHTTPClientBuilder() HTTPClientBuilder {
return &HTTPClientBuilder{
timeout: 30 time.Second,
headers: make(map[string]string),
}
}
func (b HTTPClientBuilder) WithTimeout(d time.Duration) HTTPClientBuilder {
b.timeout = d
return b
}
func (b HTTPClientBuilder) WithTransport(t http.Transport) *HTTPClientBuilder {
b.transport = t
return b
}
func (b HTTPClientBuilder) WithHeader(key, value string) HTTPClientBuilder {
b.headers[key] = value
return b
}
func (b HTTPClientBuilder) Build() http.Client {
client := &http.Client{
Timeout: b.timeout,
Transport: b.transport,
}
if client.Transport == nil {
client.Transport = http.DefaultTransport
}
// 注意：http.Client 不支持运行时修改 Header，此处仅示意逻辑
return client
}
调用时清晰可读：NewHTTPClientBuilder().WithTimeout(5 * time.Second).WithTransport(myTransport).Build()。
立即学习“go语言免费学习笔记（深入）”；
- 所有设置方法都接受明确语义的参数，比传 struct 或 map 更安全
-
Build()是唯一产生副作用（创建对象）的地方，方便单元测试 mock - 如果某字段必须设置（如 URL 模板），可在
Build()中 panic 或返回 error，而不是静默忽略
什么时候不该用 Builder：三个明显信号
Builder 不是银弹。以下情况用简单构造函数或字面量更合适：
- 结构体字段少（≤3 个），且无必填/选填逻辑 —— 直接用
MyStruct{Field: val}更轻量 - 构建过程需要异步或依赖外部状态（如从配置中心拉取参数）—— 这已超出 Builder 职责，应交给 Factory 或 Service 层
- 目标类型本身是 interface，且实现类不止一种 —— 此时 Builder 容易变成类型分支堆积，不如用策略模式 + 注册表
尤其注意：不要为每个 model 都配一个 Builder。Go 生态中，encoding/json、database/sql 等标准库几乎都不用 Builder，它们靠良好命名的字段和文档达成可读性。
Builder 和 Option 模式怎么选
Go 社区更流行的是 Option 模式（如 grpc.Dial(..., grpc.WithTimeout(...))），它用函数类型封装配置逻辑。相比 Builder，Option 更灵活、更易组合、也更符合 Go 的函数式风格。
Builder 适合字段多、有顺序依赖或需中间校验的场景（例如构建 SQL 查询对象时，Where() 必须在 Select() 后调用）；而 Option 更适合扁平、正交的配置项（如日志级别、重试次数、是否启用 TLS）。
- Builder 实例持有状态，生命周期需管理；Option 是无状态函数，可复用、可缓存
- Option 组合时顺序无关，Builder 链式调用隐含顺序假设，容易误用
- 混合使用也可行：用 Option 初始化 Builder，再用 Builder 做复杂组装
真正麻烦的是字段间存在隐式约束（比如设置了 WithTLS() 就必须禁用 WithInsecure()），这类逻辑放在 Builder 的 Build() 里检查最稳妥，Option 很难优雅表达。
