func(*t) 是唯一靠谱的 option 类型：它语义清晰、支持类型推导与 ide 跳转、可组合无副作用，被 grpc/otel/uber 广泛采用；interface 或 struct 变体在可读性、校验、扩展性上均存在硬伤。
为什么 func(*T) 是唯一靠谱的 Option 类型
Go 里所有花哨变体（interface、struct、泛型 Option[T]）最终都会在可读性、IDE 支持或扩展性上翻车。真正稳定、被 gRPC / OTel / Uber 规范长期采用的，只有 type Option func(*T) 这一种定义。
常见错误是写成 type Option interface{ Apply(*T) }：调用时失去类型推导，WithTimeout(30*time.Second) 传错类型编译器不报错；写成 type Option struct{ Timeout time.Duration } 更糟——它只是个数据包，没法做校验、不能组合、字段漏传无声无息。
-
func(*T)天然支持闭包捕获参数，语义清晰（WithName("foo")就是“设名字”，不是“建一个名字配置对象”） - IDE 能直接跳转到
WithName定义，补全也准 - 构造函数里
for _, opt := range opts { opt(t) }一行就能统一 apply，没额外抽象成本
WithXxx 函数必须只改字段，不干别的
选项函数不是初始化钩子。它的唯一职责是：接收 *T 指针，原地修改字段。任何副作用（启动 goroutine、打开文件、HTTP 请求、日志打点）都会破坏构造函数的轻量性和可预测性。
典型踩坑：
- 在
WithLogger里检查logger == nil并 panic —— 应该让调用方自己决定是否传 nil，构造阶段不拦截 -
WithTLS里直接tls.LoadX509KeyPair(cert, key)—— 这属于运行时行为，应延迟到Server.Listen()阶段 - 闭包捕获大对象，比如
func(s *Server) { s.client = http.DefaultClient }看似没问题，但若http.DefaultClient被外部修改，会意外影响所有已创建的 Server 实例
NewXxx 构造函数里默认值和 apply 顺序不能乱
先设默认值，再遍历 apply Option —— 这个顺序决定了用户能否“覆盖默认值”。如果反过来，用户传的 WithTimeout 可能被后续硬编码的 s.timeout = 30 * time.Second 覆盖掉。
正确结构：
func NewServer(addr string, port int, opts ...Option) *Server {
s := &Server{
addr: addr,
port: port,
timeout: 10 * time.Second, // 默认值在此设
maxConn: 100,
}
for _, opt := range opts {
opt(s) // 用户选项在此生效，后写的覆盖先写的
}
return s
}
- 不要在
opt(s)里做深拷贝或资源预分配（比如提前 dial TCP） - 如果某个字段必须非空（如
CertFile），校验逻辑放最后，别塞进某个 WithXxx 里 - 支持空切片：
NewServer("localhost", 8080)必须能跑，不能 panic
什么时候不该用 functional options
不是所有构造都适合套这个模式。最常被忽略的边界是：当配置项少于 3 个、且几乎不扩展时，强行上 functional options 反而增加认知负担。
- 像
os.OpenFile(name string, flag int, perm FileMode)这种稳定三参数函数，加一层OpenFile(name, WithFlag(os.O_RDONLY), WithPerm(0644))纯属画蛇添足 - 如果结构体本身已是配置载体（如
tls.Config），再套一层 Option 容易引发歧义：“我该传tls.Config还是WithTLSConfig？” - 高频创建对象（比如每毫秒新建数千个
Request）时，每个WithName都要分配一个闭包，微小开销可能累积 —— 这时回归具名参数更实在
真正该用 functional options 的场景只有一个：你已经改过三次构造函数签名，而且下次需求还没来。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
