go选项模式应直接用函数式选项：type option func(config)，每个选项函数修改config，构造函数遍历执行opts；避免接口/结构体抽象、字段零值歧义、隐式依赖及闭包陷阱，校验和io推迟到new时统一处理。
Go 选项模式怎么写才不绕弯子
直接用函数式选项，别搞结构体嵌套或 builder 链式调用。核心是让每个选项是一个接收 *Config 的函数，类型为 func(*Config)，构造函数只收一个 ...Option 参数。
常见错误是把 Option 定义成接口或带方法的结构体，结果要实现一堆无意义的 Apply()，反而增加心智负担。Go 不需要抽象到那个程度。
- 定义类型：
type Option func(*Config) - 每个选项函数直接修改传入的
*Config，比如WithTimeout(d time.Duration)内部做c.timeout = d - 构造函数里用循环执行所有
opts：for _, opt := range opts { opt(c) }
为什么不用 struct 字段默认值 + 可变参数模拟选项
因为字段可读性差、零值干扰强、无法区分“用户没设”和“用户设了零值”。比如 Timeout: 0 是想禁用超时，还是忘了设？靠注释或额外布尔字段（TimeoutSet bool）只会让 API 更难用。
选项模式天然解决这个问题：只有显式调用了 WithTimeout(5 * time.Second)，才会生效；不调用，就保持初始化时的默认值（比如 time.Second），且这个默认值在构造函数内部可控。
立即学习“go语言免费学习笔记（深入）”；
- struct 默认值方式：字段暴露、语义模糊、扩展性差（加新字段就得改构造函数签名）
- 选项模式：字段可私有、意图明确、新增选项不破坏兼容性
- 性能上几乎无差异——只是多一层函数调用，编译器通常能内联
Option 函数里容易踩的坑
最常掉进去的是在选项函数里捕获外部变量，导致多个实例共享同一份状态。比如闭包引用了循环变量，或者误把指针传进去了却没解引用。
另一个坑是选项之间有隐式依赖，比如 WithTLSConfig() 必须在 WithURL() 之后调用才生效，这种设计会让使用者困惑且难测试。
- 避免在
func(*Config)里引用外部变量，尤其不要在循环中创建选项函数 - 每个选项应幂等、无副作用、不依赖其他选项顺序
- 如果真有依赖（比如证书路径必须先设 URL 才能校验），应在
NewClient()最后统一检查，报错信息里明确指出缺失前置条件 - 不要在选项里做 heavy 初始化（如打开文件、连接 DB），那不属于配置阶段该干的事
要不要给 Option 加 context 或 error 返回
不需要。标准库和主流项目（gRPC、sqlx、ent）都坚持 func(*T) 签名。加 context.Context 会强迫调用方传，但配置加载本就不该阻塞或取消；加 error 返回会让调用链变得冗长，而真正可能出错的其实是后续的初始化逻辑，不是配置本身。
如果某个选项确实需要校验（比如 URL 格式），应该在构造函数里集中做，而不是分散到每个 Option 中。这样既统一了错误处理位置，也避免了部分选项成功、部分失败的中间态。
- Option 函数只负责赋值或简单转换（如字符串转 int）
- 复杂校验、资源获取、IO 操作一律推迟到
NewXxx()返回前完成 - 错误信息要具体，比如 “invalid timeout: must be > 0”，而不是 “failed to apply option”
事情说清了就结束。真正难的不是写出选项模式，而是判断哪些字段值得做成选项——别把每个小配置都塞进去，否则 API 表面灵活，实则难以维护。
