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 很难优雅表达。