Go 中 Builder 模式需用私有字段、链式方法和 Build() 统一校验实现，避免空值漏检；不依赖语言特性，而靠结构体设计与运行时检查保障必填字段、互斥约束与状态一致性。
Builder 模式在 Go 里不是靠继承或抽象类实现的
Go 没有构造函数重载、没有 abstract class、也不支持方法重写，所以照搬 Java/C# 的 Builder 写法会卡在第一步：编译不过。Build() 方法返回什么？怎么保证必填字段不被跳过？这些不能靠语言特性兜底，得靠结构体字段 + 方法链 + 编译期约束来补。
常见错误是直接定义一个空 Builder 结构体，所有字段全公开，然后写一堆 WithXxx() 方法返回指针——结果用户能绕过校验，Build() 时才发现 name 是空字符串，但对象已经部分构造完了。
- 用私有字段 + 公开构造函数（如
NewUserBuilder()）控制入口 -
WithXxx()方法必须返回*Builder，且只设对应字段，不校验（留到Build()） -
Build()是唯一出口，里面做必填校验、默认值填充、终态一致性检查 - 不要让
Builder实现目标类型的接口——它只是构造器，不是替代品
如何防止 Build 前漏掉关键字段
没校验的 Build() 就是摆设。比如构造 HTTPClient，Timeout 和 Transport 都是实际运行时必需的，但 Go 不支持“未赋值字段编译报错”，只能靠运行时 panic 或返回 error。
推荐在 Build() 里做显式检查，并提前暴露问题：
- 用
if b.timeout == 0这类判断，而不是依赖零值语义（比如time.Duration零值是 0s，但可能真需要 0s） - 对字符串字段，区分
""是用户有意设空，还是根本没调用WithName()—— 解法是加一个nameSet bool字段标记 - 如果业务上某些字段组合互斥（如
WithTokenAuth()和WithBasicAuth()不能共存），就在Build()里检查冲突并返回error
示例：if b.name == "" { return nil, fmt.Errorf("name is required") }
为什么不用函数式选项（Functional Options）代替 Builder
函数式选项（如 func(*T) 类型的 Option）更 Go 风格，也轻量。但它不适合字段多、有依赖关系、需分步构造的场景。
比如要构造一个带重试策略、熔断器、指标上报的 ServiceClient，你得写：NewServiceClient(WithRetry(3), WithCircuitBreaker(...), WithMetrics(...))。问题来了：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 参数顺序无关，但逻辑上有先后：熔断器要基于重试后的失败统计，顺序乱了行为不可控
- 没法在中间插入校验（比如 “用了熔断就必须配超时”）
- 无法复用中间状态（比如先配置好重试和超时，临时保存，稍后加 metrics 再 build）
- IDE 对
WithXxx的提示不如链式调用直观，尤其参数多的时候
Builder 不是银弹，但当你发现 Option 列表超过 5 个、且存在隐含约束时，就该切 Builder 了。
Builder 方法链容易踩的内存坑
链式调用看着优雅，但每个 WithXxx() 都返回 *Builder，如果 Builder 里嵌了大结构体（比如缓存 map、预分配 slice），每次复制成本就高了。
典型错误是把原始数据结构直接塞进 Builder 字段，然后在 WithXxx() 里修改它：
func (b *Builder) WithHandlers(hs []Handler) *Builder {
b.handlers = hs // 错！外部改 hs 会影响 b
return b
}
正确做法：
- 对 slice/map 等引用类型，
WithXxx()里做深拷贝或只存只读快照 - Builder 字段尽量保持小而轻：用指针或 ID 替代完整结构体
- 如果目标对象本身很大（比如含
[]byte），Builder 应只负责元信息，真正数据延迟加载或由调用方传入
Builder 的本质是“构造意图”的记录器，不是数据容器。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
