go数据库配置需用functional option模式而非struct初始化，因环境差异（如测试禁用连接池、生产调最大空闲数）要求灵活覆盖，且避免破坏兼容性、字段遗漏与全局变量污染；选项函数须纯、顺序敏感、深拷贝可变字段。
Go 数据库驱动配置为什么不能只靠 struct 初始化
因为硬编码字段无法覆盖不同环境的差异化需求，比如测试环境要禁用连接池、生产环境要设置最大空闲连接数，而直接 new 一个 sql.DB 配置 struct 会导致每次新增配置都要改构造函数签名，破坏兼容性。
- Go 标准库的
sql.Open只接受 driverName 和 dataSourceName，不暴露底层连接参数 - 第三方驱动（如
pgx、mysql）虽提供 config struct，但字段多、默认值隐晦，直接初始化易漏设关键项 - 测试时想临时替换
ConnectTimeout或 mockHealthCheckInterval，没选项模式就得写 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，这种约束必须写在文档里，不能靠使用者猜
