functional options 模式通过可选、可组合的函数配置结构体，解决 go 中无构造函数重载和默认参数导致的初始化冗余问题；它统一用 func(*options) 类型，集中应用、顺序执行、后覆盖前，并明确配置契约。
什么是 functional options 模式，它解决什么问题
Go 里没有构造函数重载，也没有默认参数，初始化一个带多配置项的服务时，容易写出一堆带大量 nil 或零值的参数的构造函数，或者干脆用一个大结构体传参——后者会导致调用方必须填满所有字段，哪怕只改一个超时时间。functional options 就是为这事设计的：把配置项变成可选的、可组合的函数，每个函数接收并修改服务的私有配置结构。
它不是语法糖，而是明确表达“哪些配置可变、谁负责设置、顺序是否重要”的契约。关键在于：选项函数类型统一（通常是 func(*options)），且只在构造时被集中应用。
怎么定义和使用 functional options 类型
先定义一个不可导出的配置结构，再定义选项函数类型：
type serverOptions struct {
addr string
timeout time.Duration
tls bool
}
<p>type ServerOption func(*serverOptions)</p><p>func WithAddr(addr string) ServerOption {
return func(o *serverOptions) {
o.addr = addr
}
}</p><p>func WithTimeout(d time.Duration) ServerOption {
return func(o *serverOptions) {
o.timeout = d
}
}</p><p>func WithTLS() ServerOption {
return func(o *serverOptions) {
o.tls = true
}
}</p>
构造函数接收可变参数 []ServerOption，按顺序 apply：
func NewServer(opts ...ServerOption) *Server {
o := &serverOptions{
addr: ":8080",
timeout: 30 * time.Second,
}
for _, opt := range opts {
opt(o)
}
return &Server{opts: o}
}
调用时清晰直观：NewServer(WithAddr(":3000"), WithTLS())。注意：选项执行顺序就是传入顺序，后设覆盖前设——比如两次 WithTimeout，后者生效。
为什么不能把 option 函数做成方法或直接暴露字段
- 如果把
WithAddr 定义成 *serverOptions 的方法，调用方就得先 new 出配置结构，破坏封装，也失去“只构造不暴露内部”的意图；
- 如果直接导出
serverOptions 字段，就等于放弃校验和默认值控制（比如 timeout 为 0 时你没法自动 fallback）；
- 更隐蔽的坑：如果选项函数内部做了副作用（如启动 goroutine、打开文件），那多次调用同一 option 就会重复触发——functional options 本身不禁止这点，但约定上它应是纯配置行为。
WithAddr 定义成 *serverOptions 的方法，调用方就得先 new 出配置结构，破坏封装，也失去“只构造不暴露内部”的意图；serverOptions 字段，就等于放弃校验和默认值控制（比如 timeout 为 0 时你没法自动 fallback）；常见错误是误把验证逻辑塞进 option 函数里：if addr == "" { panic(...) }。验证应该放在 NewServer 内部，而非每个 option 里重复判断。
什么时候该加 validation 或 chaining 支持
多数服务不需要。但若配置间存在强依赖（比如启用 TLS 时必须提供证书路径），就把校验提到构造函数末尾：
func NewServer(opts ...ServerOption) (*Server, error) {
o := &serverOptions{...}
for _, opt := range opts {
opt(o)
}
if o.tls && o.certPath == "" {
return nil, errors.New("certPath required when TLS enabled")
}
return &Server{opts: o}, nil
}
另一个真实需求：有些选项需要“链式”行为，比如日志级别 + 日志输出目标。这时不要硬塞进一个 WithLogger，而是拆成 WithLogLevel 和 WithLogOutput，保持正交。强行合并会让 option 变得难复用、难测试。
真正容易被忽略的是：functional options 模式本身不提供线程安全保证。如果多个 goroutine 并发调用同一个 ServerOption 函数（比如闭包捕获了外部变量），结果不可预期。所以 option 函数体内别读写共享状态，只操作传入的 *serverOptions。
