Functional Options模式本质是用函数类型封装配置逻辑的惯用法，将零散构造参数转为可组合、可复用的func(*T)切片，初始化时遍历执行以修改字段。
Functional Options模式本质是啥
它不是语法糖，而是用函数类型封装配置逻辑的惯用法。核心就一条：把构造参数从一堆零散参数，变成一个可组合、可复用的func(*T)切片。对象初始化时遍历执行这些函数，逐个修改内部字段。
- 直接传参（比如
NewClient(host, port, timeout, retry)）一旦参数超过4个，调用端极易错位或漏填 - 用结构体传参（
type ClientOpt struct{ Host string; Timeout time.Duration }）看似清晰，但字段必须全设、无法校验必填项、扩展性差 - Functional Options 把“设 host”“设 timeout”拆成独立函数，调用时只写关心的，顺序无关，还能链式叠加
怎么写一个靠谱的Option类型
先定义类型别名，再为每个配置项写工厂函数。关键点在于：所有 Option 函数都接收指针并原地修改，不返回新对象。
type Option func(*Server)
<p>func WithAddr(addr string) Option {
return func(s *Server) {
s.addr = addr
}
}</p><p>func WithTimeout(t time.Duration) Option {
return func(s *Server) {
s.timeout = t
}
}</p><p>func WithLogger(l <em>log.Logger) Option {
return func(s </em>Server) {
s.logger = l
}
}- 工厂函数名统一用
WithXxx命名，语义明确，IDE 自动补全友好 - 每个函数只做一件事，避免在
WithTimeout里顺手改了logger - 不要返回错误 —— 配置阶段不该失败；真要校验（比如地址格式），应在
Apply或Build阶段抛 panic 或返回 error
构造函数里怎么安全应用Options
构造函数接收变参 ...Option，按顺序执行。注意两点：默认值初始化必须在 Options 执行前完成，且 Options 应支持空切片。
func NewServer(opts ...Option) *Server {
s := &Server{
addr: "localhost:8080",
timeout: 30 * time.Second,
logger: log.Default(),
}
for _, opt := range opts {
opt(s)
}
return s
}- 默认值必须显式写死，不能靠零值（比如
timeout time.Duration的零值是 0，直接用会出问题） -
opts ...Option允许不传任何 Option，此时range opts是空循环，安全 - 别在循环里做耗时操作（比如网络请求、文件读取）—— Options 应该是纯配置行为
- 如果需要强制校验（如
addr必须非空），可在循环后加检查：if s.addr == "" { panic("addr required") }
容易踩的坑：Option被重复应用或覆盖
Functional Options 是“最后写入生效”，如果多个 Option 修改同一字段，后调用的会覆盖前面的。这本身不是 bug，但容易误用。
立即学习“go语言免费学习笔记（深入）”；
- 错误示范：
NewServer(WithTimeout(10<em>time.Second), WithTimeout(5</em>time.Second))→ 最终 timeout 是 5s，但调用者可能没意识到 - 更隐蔽的是 Option 内部依赖其他字段：比如
WithTLSConfig依赖addr已设置，但若用户漏传WithAddr，运行时才 panic - 还有并发场景：如果
Server是可变对象，且多个 goroutine 同时调用Apply类方法，Option 函数没加锁就会竞态
最常被忽略的一点：Option 函数本身不是线程安全的。如果你把某个 Option 存起来反复用（比如全局变量 defaultOpt = WithTimeout(...)），而它内部捕获了局部变量或闭包状态，那每次调用行为可能不一致。写的时候就得想清楚：这个 Option 是无状态的纯函数，还是带上下文的临时快照。
