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 个）、变化频率低、且大部分字段都有合理默认值时，直接用结构体字面量更轻量。

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，结果导致构建失败时堆栈难读、错误信息模糊。