Builder模式在Go中多数属过度设计，仅当需校验链、强依赖字段或构建有副作用时才适用；优先选用函数式选项、嵌套默认值配置或场景化工厂函数。
Builder模式在Go里多数时候是过度设计
Go语言没有构造函数重载，也没有默认参数，看起来适合用Builder封装复杂初始化逻辑——但实际项目中，90%的场景用结构体字面量 + 零值语义就足够了。struct{} 的可读性、性能和维护成本都优于手写 Builder 类型。只有当对象创建涉及：校验链、依赖注入、异步预处理、或需复用同一组参数构建多个实例时，才值得引入Builder。
哪些情况真需要Builder？看三个硬指标
判断是否该加 Builder，盯住这三个信号：
- 初始化过程必须调用
Validate()或Build()才能拿到最终对象（比如配置未填全就 panic） - 字段之间有强依赖，例如设置
WithTLSConfig()后必须调用WithTimeout()，否则运行时报错 - 构建逻辑本身有副作用，比如打开文件、连接数据库、加载证书——这些不该放在结构体字段赋值阶段
替代方案比Builder更Go风格
比起手写一整套 NewXXXBuilder() + WithXXX() + Build()，优先考虑：
- 函数式选项（Functional Options）：
func(*Config) error类型的闭包切片，传给NewClient(opts...Option) - 配置结构体嵌套默认值：
type Config struct { Timeout time.Duration `default:"30s"` }，配合mapstructure或envconfig解析 - 工厂函数按场景分组：
NewHTTPClientProd()、NewHTTPClientTest()，而不是靠Builder组合
它们更轻、更易测试、不增加类型系统负担，也符合Go“少即是多”的惯性。
写了Builder反而容易踩的坑
一旦决定用Builder，注意这几个隐性成本：
- 每个
WithXXX()方法都要返回*Builder，但Go没有泛型约束时，容易漏掉return b导致静默失败 - Builder实例不是线程安全的，如果被多个goroutine并发调用
WithXXX()，字段可能被覆盖 - IDE无法推导最终结构体字段，
builder.Build().DoSomething()中的DoSomething往往没提示 - 单元测试要 mock Builder 行为时，比直接传 config 结构体麻烦得多
真正难的是权衡“未来可能扩展”和“现在够用就行”——Go项目里，后者赢的概率更高。
