option接口比结构体字段赋值更可控，因其将初始化逻辑收束到函数中，强制约束设置顺序与依赖关系，并支持校验、联动及懒初始化，避免字段遗漏、空指针panic和隐式覆盖等问题。
为什么 Option 接口比结构体字段赋值更可控
直接给大结构体塞 10+ 个字段，哪怕全加了默认值，调用方也得记住哪些必填、哪些可空、哪些组合才合法。用 Option 接口把初始化逻辑收束到函数里，能强制约束字段设置顺序和依赖关系。
典型错误是把 Option 写成无状态的纯函数（比如只返回一个字段值），结果无法做校验或联动处理。真正有用的 Option 必须持有对目标对象的引用或修改能力。
-
Option类型定义为函数类型：type Option func(*Config)，不是func() *Config - 每个
WithXXX函数内部必须显式修改传入的*Config，不能只构造新值再丢弃 - 初始化时用可变参数接收所有
Option，按顺序执行 —— 顺序可能影响行为（比如WithTimeout要在WithRetry之后才生效）
WithTimeout 和 WithDeadline 别混用，底层字段冲突会静默覆盖
很多库的配置结构体里同时存在 timeout 和 deadline 字段，但语义互斥。如果两个 Option 都往同一个 struct 字段写（比如都改 c.ctx），后调用的会彻底覆盖前者的上下文。
常见现象：调用 NewClient(WithTimeout(5*time.Second), WithDeadline(t))，结果超时逻辑失效，因为 WithDeadline 重置了整个 context.Context，连带把 timeout 控制取消了。
立即学习“go语言免费学习笔记（深入）”；
- 检查目标结构体是否已有
ctx字段；如果有，WithTimeout应该基于现有ctx派生，而不是替换 - 如果结构体没存
ctx，而是存timeout time.Duration，那WithDeadline就不该存在 —— 它属于更高层控制，不该塞进初始化选项 - 测试时故意交换两个 option 的顺序，看行为是否变化；变化就说明有隐式依赖，得在文档里写清楚
嵌套结构体字段初始化容易漏掉中间层指针
比如 Config 里有个 HTTP *HTTPConfig 字段，而 HTTPConfig 本身也有多个字段。直接写 WithHTTPTimeout(30*time.Second) 时，如果没先初始化 HTTP 指针，就会 panic。
错误写法：func WithHTTPTimeout(d time.Duration) Option { return func(c *Config) { c.HTTP.Timeout = d } } —— c.HTTP 是 nil，一访问就崩。
- 所有操作嵌套字段的
Option，开头必须判空并懒初始化：if c.HTTP == nil { c.HTTP = &HTTPConfig{} } - 别指望调用方“记得先调
WithHTTP”，选项模式的价值就在于单点可靠，每个 option 自包含 - 如果嵌套层级深（比如
c.Logger.Output.File.Path），考虑拆成多级 option（WithLogger→WithLogOutput→WithLogFile），而不是堆一个巨长函数名
性能敏感场景下避免重复构造临时对象
每次调用 WithXXX 都 new 一个 map、slice 或 string，初始化完又扔掉，在高频创建对象（如每请求新建 client）时会明显抬高 GC 压力。
典型例子：func WithHeaders(h map[string]string) Option { return func(c *Config) { c.headers = copyMap(h) } } —— copyMap 每次都 malloc 新 map。
- 如果字段是只读的（如 headers 不会后续修改），直接赋值指针更省：
c.headers = h，前提是调用方保证传入 map 不会被外部修改 - 需要防御性拷贝时，复用 sync.Pool 分配 map/slice，别每次都 make
- 字符串拼接类 option（如
WithBaseURL）优先用strings.Builder，不用fmt.Sprintf
最麻烦的其实是 option 组合的副作用 —— 比如 WithDebug 开启日志的同时悄悄改了重试策略。这种隐式耦合没法靠类型系统拦住，只能靠 review 和文档标注清楚哪些 option 会触发额外行为。
