选项模式通过函数式配置提升可维护性：新增参数无需修改调用点，语义清晰、顺序无关、保障封装性；但参数少且稳定时应优先用直接参数列表。
为什么直接传 struct 指针会越来越难维护
当你给一个函数或构造器加到第 5 个参数，尤其是其中 3 个是 bool 或 string 类型时，调用方根本记不清哪个位置对应哪个含义。更糟的是，后续新增配置项还得改所有调用点，一动全动。
选项模式本质是把「可选参数」封装成函数，每个函数只负责设置一个字段，最终通过组合方式注入目标对象。它不是语法糖，而是为扩展性让渡一点初始化成本。
- 每次新增配置项，只需定义新选项函数，不破坏已有调用
- 调用方只传关心的选项，顺序无关，语义清晰（比如
WithTimeout(30*time.Second)） - 底层对象字段可以保持私有，避免外部直接赋值破坏不变性
Functional Options 的标准写法长什么样
核心就三样：一个接收者类型（通常是结构体指针）、一组以 func(*T) 为签名的选项函数、一个接受变参 ...func(*T) 的构造函数。
常见错误是把选项函数设计成返回 *T —— 这会导致无法链式组合；或者把选项函数做成闭包捕获外部变量，结果并发时状态错乱。
- 选项函数必须是无状态的，只修改传入的
*T - 构造函数内部要按顺序 apply 所有选项，顺序会影响最终值（比如两个
WithLogOutput，后一个会覆盖前一个） - 默认值应在构造函数里一次性设置，不要分散在各个选项中
示例：
type Server struct {
addr string
timeout time.Duration
logLevel int
}
<p>type Option func(*Server)</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill6460" title="Golang Naming"><img
src="https://img.php.cn/upload/skill/000/000/081/179094616043400.jpg" alt="Golang Naming" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/skill6460" title="Golang Naming" class="overflowclass">Golang Naming</a>
<p class="overflowclass">Go（Golang）命名规范 — 包括包、构造函数、结构体、接口、常量、枚举、错误、布尔值、接收器、getter/setter、函数等。</p>
</div>
<a rel="nofollow" href="/xiazai/skill6460" title="Golang Naming" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div><p>func WithAddr(addr string) Option {
return func(s *Server) {
s.addr = addr
}
}</p><p>func WithTimeout(d time.Duration) Option {
return func(s *Server) {
s.timeout = d
}
}</p><p>func NewServer(opts ...Option) <em>Server {
s := &Server{
addr: ":8080",
timeout: 5 </em> time.Second,
logLevel: 1,
}
for _, opt := range opts {
opt(s)
}
return s
}</p>
什么时候不该用 Functional Options
如果只有 1–2 个可选参数，且类型不同、使用频率高（比如 NewClient(url, token)），硬套选项模式反而增加认知负担。Go 官方库也大量使用简单参数列表，比如 http.NewRequest。
另一个典型误用场景是：把本该由调用方控制的逻辑塞进选项函数里，比如在 WithRetryPolicy 里启动 goroutine 或打开文件——这会让构造过程产生副作用，违背“配置即声明”的原则。
- 参数少、稳定、调用密集 → 直接参数列表更合适
- 需要运行时动态决策（如根据环境变量条件启用某选项）→ 先做判断，再传对应
Option，别把 if-else 塞进选项函数体 - 选项之间有强依赖（如必须先设
WithLogger才能设WithTrace）→ 模式本身不解决依赖，得靠文档或 panic 提示
容易被忽略的兼容性细节
很多人实现完就以为结束了，但实际上线后常遇到两类问题：一是升级 SDK 后老代码编译不过，二是多个模块各自定义同名选项导致冲突。
关键点在于命名空间和导出控制。比如你定义了 WithTimeout，但标准库或第三方库也有同名函数，Go 不会报错，但行为可能不符合预期。
- 选项函数名尽量带前缀，比如
HTTPWithTimeout或DBWithMaxOpen，尤其当包可能被广泛复用时 - 不要把选项函数放在公共接口里（如
type Configurer interface { Apply(*T) }），这会让实现者被迫暴露内部细节 - 如果支持零值回退（比如传
0表示禁用），一定要在文档里明确写出，而不是靠使用者猜
最麻烦的其实是测试：选项函数本身没副作用，但组合后的对象行为得覆盖各种排列，尤其是边界值交叉场景。别跳过 NewServer(WithTimeout(0), WithAddr("")) 这种用例。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
