database/sql 不能直接用反射切换驱动，因为 sql.open 仅识别已通过 init() 函数注册的驱动名，而反射无法触发未导入包的 init 或动态加载驱动代码；必须显式 import 对应驱动包，反射只能用于选择已注册驱动名，不可替代 import。
为什么 database/sql 不能直接用反射切换驱动
因为 database/sql 的 sql.Open 只认注册过的驱动名（如 "mysql"、"postgres"），而驱动本身是通过 init() 函数调用 sql.Register 注册的——反射无法触发未导入包的 init，更不能“动态加载”驱动代码。
常见错误现象：sql: unknown driver "sqlite3" (forgotten import?)，即使你用反射读到了字符串 "sqlite3"，但没真正 import _ "github.com/mattn/go-sqlite3"，就必然 panic。
- 必须在编译期显式导入所有可能用到的驱动包，哪怕只用其中一种
- 反射只能用于选择已注册的驱动名，不能替代 import
- 驱动注册是全局副作用，重复注册会 panic，所以不要在反射逻辑里反复调
sql.Register
如何用反射安全地构造不同数据库的 *sql.DB
核心思路：把驱动名、连接字符串、可选配置封装成结构体，用反射匹配预设的驱动初始化函数，而不是试图反射调用 sql.Open 本身。
示例场景：配置文件指定 driver: "pgx"，你要自动走 pgxpool.Connect；若为 "mysql"，则走标准 sql.Open。
立即学习“go语言免费学习笔记（深入）”；
- 定义一个映射表：
map[string]func(string) (*sql.DB, error)，键是配置里的驱动名，值是对应初始化函数 - 用反射读取配置结构体字段时，确保字段类型是
string，且值在映射表中存在，否则提前报错 - 避免对
*sql.DB做深度反射操作（比如尝试修改内部字段），它不是设计来被反射修改的
drivers := map[string]func(string) (*sql.DB, error){
"mysql": func(dsn string) (*sql.DB, error) { return sql.Open("mysql", dsn) },
"postgres": func(dsn string) (*sql.DB, error) { return sql.Open("postgres", dsn) },
"pgx": func(dsn string) (*sql.DB, error) { return pgxpool.Connect(context.Background(), dsn) },
}
reflect.Value.Call 调用驱动函数时容易崩在哪
反射调用函数最常掉进两个坑：参数类型不匹配、返回值数量/类型不对。尤其是数据库驱动函数往往返回 (*sql.DB, error)，少一个或类型错都会 panic。
错误现象：reflect: Call using zero Value argument 或 reflect: Call of non-nil function with zero value，通常是因为传入了 nil 的 reflect.Value 或函数本身是 nil。
- 务必检查映射表中取出的函数是否非 nil：
if fn == nil { return nil, fmt.Errorf("no driver registered for %s", driverName) } - 参数必须包装成
[]reflect.Value，且每个元素都要用reflect.ValueOf(...)显式转换，不能直接传字符串 - 调用后要检查返回值长度（应为 2），再分别取
.Interface()转回*sql.DB和error
适配器里要不要把 *sql.DB 包一层再反射
不要。包一层（比如自定义 DBAdapter 结构体）再对它做反射，只会增加间接层、掩盖真实问题，而且无法绕过驱动注册和连接池生命周期管理这些硬约束。
真正该抽象的是“怎么打开”和“怎么关闭”，而不是“怎么反射”。比如统一暴露 Open() error 和 Close() error 方法，内部按驱动分发即可。
- 反射适合做配置到行为的路由，不适合做运行时类型擦除
- 如果用了
pgxpool.Pool，它和*sql.DB接口不兼容，强行塞进同一反射路径会导致后期维护成本飙升 - 最容易被忽略的一点：不同驱动对 DSN 的解析逻辑差异极大（比如
postgres支持 URL 形式，mysql对 query 参数敏感），反射无法帮你校验 DSN 格式是否合法
