functional options 更优，因其避免新增字段需改调用点、消除零值语义歧义、支持配置项级校验；核心实现含私有 config、Option 函数类型、变参构造函数，校验须在 option 内而非构造函数中。
为什么直接传结构体指针不如用 functional options
Go 里初始化一个带多个可选配置的组件，最直觉的做法是定义一个 Config 结构体，然后传指针进去。但很快会遇到三个现实问题：新增字段要改所有调用点、零值语义模糊（比如 Timeout = 0 到底是“不设超时”还是“禁用超时”）、没法做参数校验前置。functional options 把每个配置项变成独立函数，组合灵活，还能在构造时集中校验。
-
func WithTimeout(d time.Duration) Option这类函数返回闭包，内部修改私有config实例 - 所有
Option类型统一为func(*config)，类型安全且可叠加 - 构造函数接收变参
...Option，顺序执行，天然支持覆盖逻辑（后设的生效）
怎么写一个最小可用的 functional options 实现
核心就三块：私有配置结构体、Option 函数类型、构造函数。别一开始就搞泛型或反射，先跑通再迭代。
- 定义私有
config结构体，字段全小写，避免外部直接访问 - 声明
type Option func(*config)，这是契约，不是接口 - 构造函数形如
NewClient(opts ...Option) <em>Client</em>，内部用默认值初始化c := &config{Timeout: 30 time.Second}，再遍历opts调用
func WithTimeout(d time.Duration) Option {
return func(c *config) {
if d > 0 {
c.Timeout = d
}
}
}注意：校验逻辑（比如 d > 0）必须放 option 函数里，而不是构造函数中——否则无法阻止用户传入无效 WithTimeout(-1)。
容易踩的坑：option 函数修改了不该改的字段
最常见的错误是 option 函数里意外覆盖了其他字段，尤其当 config 里有切片、map 或嵌套结构时。
立即学习“go语言免费学习笔记（深入）”；
- 切片字段不要直接赋值
c.middleware = mw，要用c.middleware = append(c.middleware, mw...)，否则清空原有中间件 - map 字段必须先判空再初始化：
if c.headers == nil { c.headers = make(map[string]string) } - 如果 option 需要深拷贝（比如传入一个
*tls.Config），记得用clone而不是直接赋值，否则外部修改会影响实例
另一个隐形坑：option 函数里启动 goroutine 或打开文件句柄。functional options 应该是纯数据操作，副作用留到 Client.Start() 之类的方法里。
什么时候不该用 functional options
不是所有场景都适合。如果配置项极少（比如就 1–2 个 bool 开关），硬套 pattern 反而增加认知负担；如果配置需要运行时动态变更，functional options 只作用于初始化阶段，此时该用 setter 方法或原子变量。
- 构造后几乎不改配置 → 适合 functional options
- 配置需热更新（如重载证书、切换日志级别）→ 改用方法或监听 channel
- 项目里已有大量
Config{Field: val}调用 → 不必强行重构，保持一致性更重要
真正麻烦的是混合场景：一部分配置初始化后固定，另一部分需运行时调整。这时候 functional options 只管“冷配置”，热配置走单独接口，边界划清楚比强求统一更实际。
