Functional Options 是一种 Go 中用于构造函数的配置模式，适用于初始化参数多、组合复杂或字段间存在依赖/互斥关系的场景，如 HTTP 客户端封装；它通过函数类型选项实现类型安全、链式调用与编译期检查，优于 map[string]interface{} 等动态配置方式。
Functional Options 是什么，什么时候该用它
Functional Options 不是 Go 语言内置语法，而是一种被广泛采纳的构造函数模式——用函数类型作为配置参数，把“可选配置”从结构体字段里解耦出来。它适合出现在你发现 NewXXX() 的参数列表越来越长、或者不同调用方需要不同组合的初始化行为时。
比如你要写一个 HTTP 客户端封装，有人要设超时，有人要加中间件，有人要换 Transport，硬塞进构造函数签名会迅速失控。Functional Options 就是为这类场景设计的。
- 不是所有结构体都需要它：简单对象（如
User{ID: 1, Name: "a"}）直接字面量初始化更清晰 - 一旦出现 >3 个可选字段，或字段之间有依赖/互斥关系（比如
WithTimeout和WithContext不能共存），就该考虑 Functional Options - 它天然支持链式调用、易测试、易扩展，但会多一层函数调用开销（实际几乎可忽略）
怎么写一个标准的 Functional Option 类型
核心是定义一个函数类型，接收指针并修改其状态；再提供一系列返回该类型的工厂函数。关键点在于：选项函数必须能安全地被多次调用，且顺序无关（除非你明确设计了依赖）。
type ClientOption func(*Client)
<p>func WithTimeout(d time.Duration) ClientOption {
return func(c *Client) {
c.timeout = d
}
}</p><p>func WithBaseURL(url string) ClientOption {
return func(c *Client) {
c.baseURL = url
}
}</p><p>func NewClient(opts ...ClientOption) *Client {
c := &Client{}
for _, opt := range opts {
opt(c)
}
return c
}注意：ClientOption 必须是函数类型别名，不是接口；opts ...ClientOption 利用了 Go 的变参机制；所有选项在 NewClient 内按传入顺序执行，所以如果有隐含顺序依赖（比如先设 URL 再设重试策略），得在文档里写清楚。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
常见坑：nil 指针、重复赋值、option 覆盖逻辑混乱
Functional Options 看似简单，但实际落地时最容易栽在三类问题上：
-
WithLogger(nil)导致后续c.logger.Info()panic —— 所有 option 函数内部必须做防御性检查，比如if logger != nil { c.logger = logger } - 多个
WithTimeout被传入，后一个会覆盖前一个，但调用方可能没意识到 —— 如果你不希望被覆盖（比如想累积重试次数），就得改用WithRetry(...)+ 内部 append，而不是简单赋值 - 把副作用藏在 option 里（比如
WithMetrics(&prometheus.CounterVec{})同时注册指标）—— 这会让NewClient变成“半初始化”，破坏纯构造语义；应拆成显式RegisterMetrics()方法
Functional Options 和 interface{} 配置方式比有什么实际差异
有人图省事用 map[string]interface{} 或结构体嵌套做配置，短期快，长期难维护。Functional Options 的优势不在语法炫技，而在编译期约束和 IDE 友好性：
-
WithTimeout(5 * time.Second)—— 类型安全，拼写错误、参数错位、单位遗漏，编译器立刻报错 -
WithTimeout("5s")—— 编译失败，不会等到运行时报panic: cannot convert string to time.Duration - IDE 能自动补全所有可用 option，而 map key 是字符串，补全失效，重构 rename 时极易漏掉
- 无法静态分析哪些 option 被高频使用或从未使用，而函数调用可被工具链追踪
Functional Options 的“复杂”其实是把设计决策提前到了编译期，换来的是后期维护成本的显著下降。真正容易被忽略的，是 option 函数本身的命名一致性 —— 比如混用 With、Set、Enable 前缀，会让使用者困惑哪个是覆盖、哪个是追加、哪个是开关。统一前缀 + 清晰动词，比模式本身更重要。
