functional options 用于解决配置语义模糊和调用接口爆炸问题，适用字段超3个、含默认值或需扩展的场景；必须使用变参 opts ...option、遍历执行、类型为 func(*t)、先初始化再覆盖、避免副作用。
Functional Options 不是用来“优化性能”的，而是解决“配置语义模糊”和“调用接口爆炸”的——如果你的结构体字段超过 3 个、有默认值、或未来要加新配置，就该用它，别犹豫。
为什么 NewClient(WithTimeout(5), WithRetries(3)) 会编译失败
常见错误现象：直接照着示例写，结果编译报 too many arguments 或 cannot use ... as type Option。根本原因是构造函数签名写错了。
- 错误写法：
func NewClient(opt Option) *Client—— 只收一个Option，Go 不会自动把多个函数打包成切片 - 正确写法：
func NewClient(opts ...Option) *Client—— 注意是...Option（变参），不是Option - 内部必须用
for _, opt := range opts遍历执行；如果漏了循环，只有第一个选项生效，其余静默丢弃
Option 类型必须是 func(*T)，不能是 func(T) 或 interface{}
这是最隐蔽也最致命的坑：语法能过，运行时完全不生效，调试时极难定位。
- 写成
func(c Client)（值传递）：每个WithXXX修改的都是副本，c原始对象字段仍是零值 - 写成
func(c *Client)（指针传递）：才能真正修改目标实例，这是 Functional Options 的底层契约 - 千万别用 interface{} 或 struct 封装 Option —— 会失去类型安全，也无法链式组合
默认值初始化必须在 apply options 之前，且所有字段都要显式初始化
典型翻车场景：用户传了 WithTimeout(10 * time.Second)，结果最终 timeout 是 30 秒。问题出在顺序和 nil 判断上。
- 错误顺序：
c := &Client{}; for _, opt := range opts { opt(c) }; c.timeout = 30 * time.Second→ 用户配置被覆盖 - 正确顺序：
c := &Client{timeout: 30 * time.Second, retries: 3, headers: make(map[string]string)}→ 先设好起点，再让 option 覆盖 - map、slice、指针字段（如
*log.Logger）必须在c := &Client{}这一步就make或取地址，否则后续WithHeaders或WithLogger会 panic
WithXXX 函数里禁止做 IO、启动 goroutine、修改全局状态
Functional Options 的语义是“声明配置”，不是“执行初始化”。一旦掺入副作用，对象就不可预测，尤其在测试或热重载时直接崩。
- 这些操作必须剥离：
ioutil.ReadFile（读证书）、net.Dial（连地址）、log.SetOutput（改全局 logger）、起监听 cancel 的协程 - 它们该延迟到
Client.Start()、Server.Listen()或首次Do()时才做 - 校验类逻辑（如 URL 解析、路径存在性）建议统一用
func(*Client) error签名，但纯赋值类（WithTimeout）保持无 error 更轻量——混用两种签名会让构造函数处理逻辑分裂
真正难的不是写几个 WithXXX 函数，而是守住“声明式”边界：不碰 IO、不改全局、不提前分配资源、所有字段在构造起点就完成合理初始化。越早意识到这点，越少半夜被线上 panic 叫醒。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
