函数选项模式是高并发服务配置的安全接口层，因其可读、可控、不易出错；结构体字面量则导致默认值分散、零值歧义、新增字段破坏兼容、序列化污染，且Option必须定义为func(*Config)而非接口。
函数选项模式本身不并发，但它是高并发服务配置的「安全接口层」——它让并发组件的初始化既可读、又可控、还不易出错。
为什么不能直接用结构体字面量传参
在高并发服务里，Server、Client、Pool 这类核心类型往往要暴露给大量 goroutine 使用。如果用结构体字面量初始化：
- 字段默认值散落在各处，比如
Timeout在调用点写0，在文档里写「默认 10s」，实际逻辑却藏在构造函数里 —— 后续改默认值必须全局 grep，极易漏 - 无法区分「用户没设」和「用户明确设为零值」，比如
MaxConns: 0是禁用连接池，还是忘了填？ - 新增字段（如加
KeepAlive）会强制所有调用点改写，哪怕它们完全不关心这个配置 - 序列化时容易把零值字段也写进 JSON/YAML，污染配置文件或 API 响应
Option 类型必须定义为函数，不是接口
常见错误是定义成 type Option interface{ Apply(*Config) }。这会导致：
- IDE 无法跳转到
WithTimeout实现，因为接口方法名不固定 - 编译器拦不住非法实现，比如传个
func() {}也能满足接口 - 失去类型推导，
opts...参数无法被静态分析工具识别为「配置行为」
正确写法只有一行：type Option func(*Config)。每个 WithXXX 返回闭包，例如：
立即学习“go语言免费学习笔记（深入）”；
func WithTimeout(d time.Duration) Option {
return func(c *Config) { c.Timeout = d }
}
这种写法让 Go 编译器能校验函数签名，也让 IDE 和 linter 能精准追踪配置流向。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
并发组件初始化时，Option 执行顺序很关键
选项按传入顺序依次执行，后设覆盖先设。这对并发资源尤其敏感：
-
WithWorkerPoolSize(10), WithWorkerPoolSize(5)→ 最终是 5 个 worker -
WithContext(ctx), WithTimeout(5*time.Second)→ 如果WithContext内部没做超时合并，可能忽略后者 -
WithTLSConfig(tlsCfg), WithInsecureSkipVerify(true)必须后置，否则会被 TLS 配置重置
不要指望调用方记得顺序。要么在文档里明确标注依赖关系，要么把有耦合的配置打包进单个 Option，比如 WithTLS(tls.Config, skipVerify bool)。
高并发场景下，Option 里别捕获大对象
闭包会隐式捕获外部变量。如果在 WithLogger 里直接引用一个已初始化的 *zap.Logger，而这个 logger 又持有一个带锁的 buffer 或后台 goroutine，就可能造成：
- 意外延长 logger 生命周期，导致资源泄漏
- 多个
Server实例共享同一个 logger 实例，但日志字段（如service_name）却被覆盖 - 在热重启或配置重载时，旧 logger 仍被新 Server 持有，无法 GC
安全做法是：Option 只存配置参数（字符串、数字、函数），具体对象构建推迟到 NewServer 内部，由构造函数统一管理生命周期。
最常被忽略的一点：函数选项模式解决的是「怎么配」，不是「配什么」；真正的并发稳定性，取决于你是否在 Apply 阶段做了校验（比如检查 WorkerPoolSize > 0）、是否对共享资源做了深拷贝、以及是否把 context 取消信号真正透传到了所有 goroutine 中。
