数据库驱动加载失败时 sql.Open 不报错，但 db.Ping() 才暴露问题
Go 的 sql.Open 只校验连接字符串格式，不真正连接数据库，也不检查驱动是否注册。常见现象是：代码编译通过、sql.Open 返回非 nil 的 *sql.DB，但后续调用 db.Query 或 db.Ping() 时才爆出 sql: unknown driver "mysql" (forgotten import?)。
根本原因是驱动没被匿名导入（即没触发其 init() 函数），导致 sql.Register 没执行。
- 必须确保驱动包被匿名导入，例如：
import _ "github.com/go-sql-driver/mysql" -
sql.Open后立即加if err := db.Ping(); err != nil { ... }，这是验证驱动+网络+权限三合一的最小成本检查 - 如果用的是旧版驱动（如
github.com/ziutek/mymysql），注意它已弃用，新项目应避免；新版go-sql-driver/mysql要求 Go 1.16+，且不兼容mysql这个旧驱动名
匿名导入 _ "driver/import/path" 是唯一触发 init() 的方式
Go 中驱动注册逻辑全在 init() 函数里，而 init() 只在包被“使用”时执行。但驱动包通常不导出任何符号，没法显式引用——所以只能靠匿名导入（下划线导入）来强制加载。
错误写法：import "github.com/go-sql-driver/mysql"（没下划线，包不会初始化）
立即学习“go语言免费学习笔记（深入）”；
正确写法：import _ "github.com/go-sql-driver/mysql"
- 匿名导入不是语法糖，是机制刚需；漏掉下划线 = 驱动未注册 =
sql.Open("mysql", ...)必然失败 - 多个驱动共存时，每个都要单独匿名导入，比如同时用 MySQL 和 PostgreSQL：
import (_ "github.com/go-sql-driver/mysql"; _ "github.com/lib/pq") - 不能把匿名导入写在子包里再“间接使用”——
init()只在直接导入的包中触发，跨包无效
import _ 后仍报 unknown driver？检查 GOPATH / Go Modules 和 vendor 冲突
即使写了匿名导入，依然出现 unknown driver，大概率是构建环境没真正包含该驱动包。
典型场景：项目启用了 Go Modules，但 go.mod 里没记录驱动依赖；或用了 vendor 目录，但驱动没被 go mod vendor 拉进去。
- 运行
go list -f '{{.Deps}}' . | grep mysql确认驱动是否在依赖树中 - 执行
go mod tidy，确保go.mod和go.sum包含驱动条目 - 若用
vendor，确认vendor/github.com/go-sql-driver/mysql/目录存在，且里面包含driver.go和init()函数 - VS Code 或其他 IDE 缓存可能导致误判，可临时用
go build -x看实际编译时加载了哪些包
init() 里做重试或日志会影响主程序启动行为
有些团队会在驱动的 init() 函数里加日志、配置加载甚至网络探测——这是危险操作。因为 init() 在 main() 执行前运行，无法控制上下文，也没法返回错误给调用方。
比如某自定义驱动在 init() 中调用 http.Get 检查服务可用性，结果因 DNS 未就绪直接 panic，整个程序启动失败。
- 驱动的
init()应只做注册（sql.Register）和极轻量初始化（如设置默认参数） - 所有 I/O、重试、日志等逻辑必须延迟到
Open或首次Ping时执行 - 如果你维护一个驱动库，别在
init()里打log.Println—— 它会出现在二进制启动第一行，且无法关闭
import _，背后连着 Go 的初始化顺序、模块依赖解析和运行时注册表三个层面。少一个环节，错误就藏得更深一点。 
