Go不用传统建造者模式，因其缺乏构造函数重载和链式调用语法糖，强行模仿Java Builder会笨重；更惯用的是结构体字面量或函数式选项（Functional Options），后者通过可变参数的配置函数按序修改结构体字段，职责单一、零分配、顺序无关。
为什么 Go 里不用传统建造者模式
Go 没有构造函数重载，也没有 this 指针链式调用的语法糖，强行模仿 Java 那套 builder().withName().withAge().build() 会显得笨重且不符合 Go 的惯用法。更自然的方式是用结构体字面量 + 可选配置函数，既清晰又无副作用。
用函数式选项（Functional Options）替代 builder 对象
核心思路：定义一个配置函数类型，每个选项函数接收并修改目标结构体指针；构建入口接受可变数量的选项函数，按顺序应用。
type Server struct {
addr string
port int
tls bool
}
type Option func(*Server)
func WithAddr(addr string) Option {
return func(s *Server) {
s.addr = addr
}
}
func WithPort(port int) Option {
return func(s *Server) {
s.port = port
}
}
func WithTLS(tls bool) Option {
return func(s *Server) {
s.tls = tls
}
}
func NewServer(opts ...Option) *Server {
s := &Server{
addr: "localhost",
port: 8080,
tls: false,
}
for _, opt := range opts {
opt(s)
}
return s
}
使用时直接传入组合好的选项：NewServer(WithAddr("api.example.com"), WithPort(443), WithTLS(true))
- 每个
Option函数职责单一，易于测试和复用 - 零分配开销：选项函数本身不分配堆内存，只在调用时修改结构体字段
- 支持任意顺序、任意子集，无需为每种组合预定义方法
- 如果某字段必须设置，应在
NewServer内部做校验，而不是依赖调用方记牢顺序
什么时候该用结构体字面量而非 Options
当配置项少（≤3 个）、变化频率低、且大部分字段都有合理默认值时，直接用结构体字面量更轻量。
立即学习“go语言免费学习笔记（深入）”；
cfg := Server{
addr: "127.0.0.1",
port: 3000,
tls: true,
}
这种写法比 NewServer(WithAddr(...), WithPort(...)) 更直观，也更容易被 IDE 自动补全和静态检查。
- 字段名即文档，无需跳转看
WithXXX函数实现 - 编译期就能发现未赋值的导出字段（如果结构体定义为不可导出字段+构造函数，则另当别论）
- 若后续新增字段但没设默认值，字面量初始化会立即报错，而 Options 方式可能静默忽略
避免在 Options 中做副作用操作
常见错误：在 WithXXX 函数里启动 goroutine、打开文件、连接数据库——这会让构建过程不可预测，也违反“构建器只负责组装”的原则。
- 所有 I/O 或耗时操作应推迟到
Start()、Run()等明确生命周期方法中 - Options 只做字段赋值或浅层验证（如检查端口号范围）
- 如果需要预处理参数（比如把字符串地址解析成
net.Addr），应在NewServer内部统一做，而不是分散在各个 Option 里
真正难的是边界判断：哪些逻辑属于“配置”，哪些属于“启动”。多数人一开始会把太多东西塞进 Options，结果导致构建失败时堆栈难读、错误信息模糊。