写 Go 构造函数时，最常见的失控点不是逻辑本身，而是参数列表越来越长：调用处既难读，也容易把零值和“未设置”混在一起。函数选项模式正好处理这类问题，下面从它要解决的痛点、基本写法，到校验、组合和适用边界，梳理出一套更适合日常项目落地的判断方法。
为什么长参数列表会变得难维护
假设我们要创建一个 HTTP 服务器，结构体里有不少配置项：
type Server struct {
Host string
Port int
Timeout time.Duration
TLS bool
CertFile string
KeyFile string
MaxConn int
}如果直接写成“全参数构造函数”，调用方即使只想覆盖其中一两个字段，也得把整串参数完整传进去：
srv := NewServer("localhost", 8080,
30*time.Second, false, "", "")这类调用有两个直接问题。第一，代码阅读时很难靠位置快速判断每个参数的含义；第二，不需要的参数也得用零值占位，时间一长，调用处会越来越像“为了满足签名而填空”。
很多人会先想到两种替代方案，但它们各自都有明显限制。
配置结构体为什么不总够用
把参数收进一个配置结构体，确实能让调用看起来整齐一些，但它很难区分“调用者没设置”和“调用者就是要设置成零值”。比如 Timeout 为 0，到底表示沿用默认值，还是明确要求不超时，这在语义上可能完全不同。
Builder 模式的问题在哪里
Builder 模式能把配置拆成链式调用，但在 Go 里往往意味着更多类型和更多样板代码。除了代码量上升，还有一个实际问题：如果使用者忘了调用 Build()，这类错误不一定能在最早阶段暴露出来。对很多并不复杂的配置场景来说，这种成本偏高。
函数选项模式怎么写
函数选项模式的思路很直接：把“可选配置”变成函数，每个函数只负责修改一个配置项。这样，调用者只传自己关心的那几项，默认值则留在构造函数内部处理。
先定义 Option 类型
type Option func(*Server)这一步的意思是：任何一个能接收 *Server 并修改它的函数，都可以视为一个选项。
再为每个配置项提供 With 函数
func WithTimeout(d time.Duration) Option {
return func(s *Server) {
s.Timeout = d
}
}
func WithTLS(certFile, keyFile string) Option {
return func(s *Server) {
s.TLS = true
s.CertFile = certFile
s.KeyFile = keyFile
}
}这里的好处是，配置项的语义被函数名直接写出来了。相比“第三个参数是超时，第五个参数是证书路径”，WithTimeout、WithTLS 的可读性要高得多。
构造函数里先给默认值，再应用选项
func NewServer(host string, port int,
opts ...Option) *Server {
s := &Server{
Host: host,
Port: port,
Timeout: 10 * time.Second,
}
for _, opt := range opts {
opt(s)
}
return s
}这里有两个关键点。其一，必填参数仍然放在函数签名里，比如 host 和 port；其二，可选参数通过 opts ...Option 传入，构造函数内部先设置默认值，再逐个覆盖。
调用方式也会变得更清晰：
srv := NewServer("localhost", 8080,
WithTimeout(30*time.Second),
WithTLS("cert.pem", "key.pem"),
)这种写法最大的价值不是“更短”，而是“调用意图更明确”。不需要的选项可以直接省略，新增配置项时也不用改动原有调用代码。
进阶用法：校验、组合与 API 控制
函数选项模式不只是让调用更好看，它还适合承载一些与配置相关的规则，比如参数约束、成组配置和公共库的对外控制。
选项之间有依赖时，统一在构造阶段校验
如果某些选项存在约束关系，通常做法是在所有选项应用完成后再检查一次：
func NewServer(host string, port int,
opts ...Option) (*Server, error) {
s := &Server{
Host: host, Port: port,
Timeout: 10 * time.Second,
}
for _, opt := range opts {
opt(s)
}
if s.TLS && s.CertFile == "" {
return nil, errors.New(
"TLS requires CertFile")
}
return s, nil
}这样做比把依赖关系分散到各个 WithXxx 里更稳妥。原因很简单：选项函数应该尽量只做单一设置，规则判断集中在构造函数，更容易维护，也更不依赖调用顺序。
经常一起出现的配置，可以做成复合选项
func WithProduction() Option {
return func(s *Server) {
s.Timeout = 60 * time.Second
s.MaxConn = 10000
}
}当某些参数组合总是成套出现时，复合选项能减少遗漏。像生产环境默认超时、连接数上限这类配置，收进一个 WithProduction() 里，会比在每个调用点重复拼接更稳定。
公共库里为什么会用接口型选项
在更偏公共 API 的场景中，google.golang.org/grpc 采用过一种变体：把选项从函数类型改成接口。
type Option interface {
apply(*Server)
}
type funcOption struct {
f func(*Server)
}
func (o *funcOption) apply(s *Server) {
o.f(s)
}这里的重点在 apply 是小写，也就是未导出方法。这样形成的是一种封闭接口（Sealed Interface）：外部包无法随意实现自己的 Option。对库作者来说，这能把配置入口控制在自己手里，避免第三方传入不可控的选项类型，同时也为内部保留实现自由，比如并不一定只能用函数来承载选项，还可以根据需要换成别的更轻量结构。
落地时的几个实践原则
命名上尽量统一使用 With 前缀
WithTimeout、WithTLS 这类命名已经是 Go 社区里的常见约定，gRPC、uber-go/zap 等项目都采用类似形式。统一前缀的好处是让调用方一眼知道“这是可选配置，而不是普通工具函数”。
尽量保持顺序无关
一个健康的选项体系，最好不要求调用者记忆先后顺序。也就是说，多数 Option 都应该独立生效，最终结果不因应用顺序不同而改变。确实存在依赖时，优先在构造函数里统一处理，不要在选项函数之间制造隐式耦合。
必填参数和可选参数要分开
适合放进 Option 的，是那些可以省略、且有默认值的字段；真正关键的必填项，仍然应该放在构造函数签名中。如果把所有字段都做成选项，调用虽然“统一”了，但调用者也更容易漏掉关键配置。
什么时候值得用，什么时候没必要用
函数选项模式并不是“只要有配置就该上”的通用答案，它更适合下面几类场景：
- 可选配置项较多
- 大部分配置都有合理默认值
- 需要对外暴露稳定、可扩展的 API
相反，如果场景只是 1 到 2 个可选参数、所有参数都属于必填项，或者这个结构体只在内部短期使用，那么直接参数传递或普通配置结构体往往更简单。为了“模式完整”而引入额外抽象，反而会把问题复杂化。
把它用对位置，价值主要体现在三点：参数可读性更高，零值歧义更少，新增配置项时也不用破坏既有调用方式。对需要长期演进的 Go API 来说，这正是它最实用的地方。
