Golang选项模式在数据库驱动配置中的灵活性体现

go数据库配置需用functional option模式而非Struct初始化，因环境差异（如测试禁用连接池、生产调最大空闲数）要求灵活覆盖，且避免破坏兼容性、字段遗漏与全局变量污染；选项函数须纯、顺序敏感、深拷贝可变字段。

Go 数据库驱动配置为什么不能只靠 struct 初始化

因为硬编码字段无法覆盖不同环境的差异化需求，比如测试环境要禁用连接池、生产环境要设置最大空闲连接数，而直接 new 一个 sql.DB 配置 struct 会导致每次新增配置都要改构造函数签名，破坏兼容性。

• Go 标准库的 sql.Open 只接受 driverName 和 dataSourceName，不暴露底层连接参数
• 第三方驱动（如 pgx、mysql）虽提供 config struct，但字段多、默认值隐晦，直接初始化易漏设关键项
• 测试时想临时替换 ConnectTimeout 或 mock HealthCheckInterval，没选项模式就得写 wrapper 或改全局变量

用 functional option 模式封装数据库配置

核心是把每个配置项变成函数类型 func(*Config)，再通过可变参数传入构造函数，这样新增选项不破坏已有调用，也避免配置 struct 暴露过多字段。

• 定义 type Option func(*Config)，所有配置函数都符合这个签名
• 构造函数接收 ...Option，内部按顺序 apply，后设的选项能覆盖前设的（比如两个 WithMaxOpenConns 调用，后者生效）
• 必须显式调用 Apply() 或类似方法触发配置合并，否则传了选项也不生效

示例：

cfg := NewConfig(WithHost("localhost"), WithPort(5432), WithDatabase("test"))

哪些配置项值得做成 option 而不是放 struct 默认值

不是所有字段都需要抽象成 option —— 只有那些在不同部署场景下**必然变化**或**需要被测试控制**的才值得。否则只是增加调用噪音。

立即学习“go语言免费学习笔记（深入）”；

• WithConnectTimeout：本地开发可设 1s，K8s 环境可能需 30s，CI 测试常设为 100ms 强制快速失败
• WithMaxIdleConns：小服务设 5，高并发服务需 50+，但设太大又浪费资源，必须可调
• WithLogger：测试时传 io.Discard，生产传结构化 logger，不做成 option 就得改 Config 结构体字段类型
• 别把 WithDriverName 做成 option —— 它属于固定依赖，该由调用方决定，不是配置策略

容易踩的坑：option 函数修改了共享 Config 实例

如果多个 goroutine 并发调用同一个 Option 函数（比如闭包里捕获了外部变量），或者在 apply 过程中没有 deep copy 字段（如切片、map、嵌套 struct），会导致配置污染。

• 所有 option 函数必须是纯函数：只读取参数，只修改传入的 *Config，不读写外部状态
• 对 Config 中的 slice/map 字段（如 QueryOptions），要在 option 内部做 shallow copy，避免 caller 后续修改影响已配置实例
• 别在 option 里启动 goroutine 或打开文件 —— 它只负责赋值，初始化动作（如建连接池）应放在 Open() 方法里

最常被忽略的是：option 的执行顺序会影响最终行为，比如 WithMaxOpenConns(10) 后跟 WithMaxIdleConns(20) 是合法的，但反过来会触发 sql 包的 panic，这种约束必须写在文档里，不能靠使用者猜