函数式选项模式通过只在显式调用时执行配置，避免了结构体零值导致的“未设置”语义丢失；option必须为接收指针的函数类型（type option func(*config)），确保修改真实对象；校验应统一放在构造函数末尾，而非单个option中。
为什么直接传结构体指针会丢失“未设置”语义
用 Config 结构体接收配置时，Timeout 字段为 0 无法区分是用户显式设为 0，还是根本没设置。Go 的零值机制让这种模糊性成为常态——int 默认就是 0，string 默认就是 ""，time.Duration 默认就是 0。
常见错误现象：你写了 WithTimeout(0)，结果发现超时被禁用了，但调用方本意可能是“不覆盖默认值”。这不是 bug，是设计缺陷。
- 改用
*time.Duration虽能区分 nil 和非 nil，但调用方得写timeout := 5 * time.Second; NewClient(WithTimeout(&timeout))，体验差 - 函数式选项模式天然规避这个问题：没传
WithTimeout就不执行，0只在显式调用时才生效，语义清晰 - 默认值统一在构造函数里初始化，所有字段都有明确起点，选项只负责“覆盖”，不参与“判断是否为空”
Option 类型定义必须接收指针，不能是值类型
如果把 Option 定义成 func(Config) Config（值传递），那每次调用都只是修改副本，最终构造出的对象仍是原始默认值——这是初学者最常踩的坑。
正确写法只能是：type Option func(*Config)。闭包内部操作的是真实内存地址，才能累积生效。
- 所有选项函数（如
WithTimeout）返回的匿名函数，参数必须是*Config，否则修改无效 - 构造函数中遍历
opts时，opt(c)的c必须是取地址后的指针，比如&Config{...}或new(Config) - 如果误写成
func(c Config)，编译不报错，但运行时所有配置都不生效，调试时极难定位
多个 Option 组合时顺序是否重要？
大多数情况下不重要，但一旦选项之间存在依赖或覆盖逻辑，顺序就关键了。比如 WithBaseURL 和 WithPath，后者可能拼接前者；又比如 WithLogger 和 WithDebugLogger，后者可能覆盖前者。
函数式选项模式本身不保证顺序，它只是按传入顺序依次调用——这意味着调用方要自己控制先后。
- 不要在
WithTimeout里读c.BaseURL做逻辑判断，因为此时WithBaseURL可能还没执行 - 若必须依赖顺序，文档里得明确写“请将
WithBaseURL放在WithPath之前”，否则使用者容易踩坑 - 更稳妥的做法是把有依赖的逻辑合并进单个 Option，比如
WithURL("https://api.example.com/v1")，内部同时设 base + path
要不要加校验逻辑？加在哪一层？
校验不能放在单个 Option 函数里——每个 Option 只负责改一个字段，它不知道其他字段状态。校验必须放在构造函数末尾，在所有 Option 应用完毕后统一做。
典型错误是：在 WithTLS 里检查 CertFile 是否为空，但此时 WithCertFile 可能还没调用，导致提前 panic。
- 构造函数返回
(*Client, error)，而不是*Client，给校验留出口 - 校验逻辑放最后：先 apply 所有 opts，再
if c.TLS && c.CertFile == "" { return nil, errors.New("TLS requires CertFile") } - 避免在 Option 内部做跨字段校验，保持每个 Option 职责单一、无副作用
实际编码中最容易被忽略的，是把校验塞进某个 Option 里，或者误以为 Option 调用顺序可由框架保证。它们都依赖调用方自觉，而人总会忘。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
