Functional Options 是首选，Builder 模式仅适用于多阶段校验、延迟逻辑或强依赖字段等极少数场景；它将配置项封装为 func(*Config) 函数，构造函数接收可变参数，语义清晰、类型安全、零耦合、易组合且天然支持向后兼容。
Go 里没有默认参数、不能重载函数，所以多参数构造必须靠设计——Functional Options 是首选，Builder 模式只在极少数场景下才值得用。
Functional Options 是什么，为什么它更符合 Go 风格
它本质是把每个配置项封装成一个 func(*Config) 类型的函数，再让构造函数接收可变数量的这些函数。调用时写成 NewServer(WithPort(8080), WithTLS(true))，语义清晰、类型安全、零耦合。
- 默认值统一收口在构造函数内部，不散落在各处
- 新增字段不破坏旧调用，老代码完全不用改
- IDE 能跳转到
WithPort定义，也能推导参数类型 - 不会意外暴露结构体字段（比如用户直接写
&Server{Port: 8080}） - 组合自由：
WithTimeout(5*time.Second), WithRetry(3)可任意顺序传，逻辑自解释
Builder 模式在 Go 中容易踩哪些坑
常见写法是 NewServerBuilder().Port(8080).TLS(true).Build()，看似链式流畅，但实际埋了不少 Go 不擅长处理的问题：
-
Builder结构体若带状态（如记录“是否已调用SetTLS”），就难以并发安全——Go 不适合靠内部标志位做流程控制 - 每个
Port()方法返回*ServerBuilder，意味着所有字段都得是可导出的，等于把校验逻辑拱手交给调用方 - 如果多个
SetXxx()之间有隐含依赖（比如SetTLSConfig()必须在SetInsecureSkipVerify()前），顺序错误会导致静默失效 - 无法静态检查必填项：你没法强制要求用户必须调用
.Addr("localhost")才允许.Build() - 复用困难：同一个
Builder实例不能被多个 goroutine 同时调用
什么时候真该用 Builder 模式
只有当构造过程需要多阶段校验、延迟执行或外部驱动的状态流转时，才考虑显式 Builder。比如：
立即学习“go语言免费学习笔记（深入）”；
- 配置项之间存在强依赖，且必须在
Build()前做跨字段校验（如 “启用了 TLS 就必须提供证书路径”） - 某些字段需在构建末尾动态生成（如自动生成唯一 ID、拼接 URL、加载远程配置）
- 构造逻辑本身要分步触发（比如先初始化连接池，再注册回调，最后启动监听）
- 你明确需要一个中间对象来承载临时状态，并且这个对象生命周期可控、不跨 goroutine
即便如此，也建议把 Builder 设计为无状态的纯配置载体，或者干脆用 Functional Options + 一个 Validate() 方法替代。
Option 函数里该不该做参数校验
不该。校验逻辑应延后到 Build() 或对象首次使用时执行。原因很实在：
-
WithTimeout(-1 * time.Second)这种非法值，在WithTimeout闭包里 panic 会打断链式调用，用户根本没机会补全其他必要选项 - 有些校验必须等所有选项都应用完才能做（比如 “timeout 必须小于 retry interval”）
- 提前 panic 让错误位置和真实问题脱节，调试时容易误判
- 测试也更麻烦：你得 mock 所有前置 Option 才能测到某一个的 panic 分支
真正该在 WithXXX 里做的，只有赋值；真正该在 Build() 或 Apply() 阶段做的，才是校验与组合逻辑。
Functional Options 的简洁性容易让人忽略它的执行顺序敏感性——后传的 Option 会覆盖先传的，而某些选项之间存在隐含依赖。这不像 Java Builder 那样有编译器或 IDE 强约束，全靠文档和约定，最容易在动态加载配置（比如从 YAML 解析出 option 列表）时出问题。
