直接传参不适合构建可扩展TCP服务器，因为每新增配置项（如超时、TLS、连接数）都需修改函数签名，调用方必须传全参数，且Go不支持默认参数和重载；而函数选项模式通过类型安全、可组合的ServerOption func(*serverConfig)实现按需配置，默认值内建、扩展无侵入。
为什么直接传参不适合构建可扩展的TCP服务器
当 TCP 服务器需要支持超时控制、日志级别、TLS 开启、连接数限制等配置时，用普通函数参数（比如 func NewServer(addr string, timeout time.Duration, enableTLS bool)）会快速失控：每加一个配置就得改函数签名，调用方必须传全所有参数，哪怕只关心其中一两个。Go 没有默认参数，也没法重载，硬塞 struct 又容易让配置项暴露成公共字段，破坏封装。
函数选项模式（Functional Options Pattern）正是为这类场景设计的——它把配置逻辑从构造函数里剥离，用类型安全、可组合、易扩展的方式表达“我只想改这个，其余保持默认”。
如何定义和实现 ServerOption 类型
核心是定义一个函数类型，接收 *serverConfig 指针并修改其字段；再让每个配置项返回该函数。这样调用时就能链式传递任意子集：
type ServerOption func(*serverConfig)
<p>type serverConfig struct {
addr string
timeout time.Duration
logger io.Writer
tlsConfig *tls.Config
maxConns int
}</p><p>func WithAddr(addr string) ServerOption {
return func(c *serverConfig) {
c.addr = addr
}
}</p><p>func WithTimeout(d time.Duration) ServerOption {
return func(c *serverConfig) {
c.timeout = d
}
}</p><p>func WithLogger(w io.Writer) ServerOption {
return func(c *serverConfig) {
c.logger = w
}
}注意点：
立即学习“go语言免费学习笔记（深入）”；
-
serverConfig必须是 unexported 结构体（首字母小写），否则用户能绕过选项直接赋值 - 每个
WithXXX函数返回的是闭包，不是立即执行，所以顺序无关紧要 - 不要在选项函数里做资源初始化（比如打开文件、启动 goroutine），那属于
NewServer的职责
怎样在 NewServer 中安全合并多个选项
构造函数接收变长 ServerOption 列表，先初始化默认配置，再逐个应用选项。关键是要确保即使传入 nil 选项也不 panic：
func NewServer(opts ...ServerOption) *TCPServer {
cfg := &serverConfig{
addr: ":8080",
timeout: 30 * time.Second,
logger: os.Stderr,
maxConns: 1024,
}
for _, opt := range opts {
if opt != nil {
opt(cfg)
}
}
return &TCPServer{cfg: cfg}
}常见错误：
- 忘记判空，导致
panic: invalid memory address—— 虽然用户一般不会传 nil，但防御性编程建议加if opt != nil - 把选项应用逻辑写在
serverConfig初始化之前，导致默认值被覆盖两次 - 在选项里修改了非指针 receiver（比如
func(c serverConfig)），实际没生效
什么时候该用函数选项，而不是结构体或 Builder
函数选项不是银弹。对比其他方式：
- 纯 struct 初始化（
ServerConfig{Addr: "...", Timeout: ...}）适合配置项少且稳定，但字段一多就难维护，且无法表达“仅覆盖某几项”的意图 - Builder 模式（
NewServer().Addr(...).Timeout(...).Build()）语义清晰，但每个方法都要返回*Builder，链式调用中一旦漏掉.Build()就得不到实例，且难以复用中间状态 - 函数选项天然支持组合复用：
devOpts := []ServerOption{WithAddr(":3000"), WithLogger(ioutil.Discard)}，测试时直接复用
真正容易被忽略的是：选项函数本身不该有副作用，也不能依赖执行顺序（比如 WithTLS 不应隐式设置 WithTimeout）。如果配置之间存在强依赖，说明抽象层级可能错了——要么拆分成多个独立服务，要么把依赖关系显式建模进 config 结构体里。
