init中初始化连接池会导致程序启动卡死或panic，因其执行同步阻塞i/o且无法被context中断；变量遮蔽更会使全局db为nil，引发后续nil pointer dereference。
别在 init 里初始化数据库或 Redis 连接池——它根本活不到“断开”的那一刻，大概率直接卡死或 panic。
为什么 init 中调用 db.Ping() 或 client.Ping() 会卡住
因为 init 是同步、单线程、无调度的执行阶段。任何阻塞 I/O（比如 DNS 解析、TCP 握手、TLS 协商）都会让整个程序停在那里，且 context.WithTimeout 完全无效：运行时此时禁止新 goroutine 调度，ctx.Done() 永远不会被 select 到。
-
sql.Open()本身不拨号，但紧跟着的db.Ping()会强制建连；同理redis.NewClient().Ping(ctx)也会触发同步阻塞 - 网络不可达、防火墙拦截、DNS 延迟超 5 秒？程序就卡 5 秒以上，且无日志输出（log 包可能都还没初始化）
- 某些封装库内部用了
sync.WaitGroup或 channel 等待，直接触发fatal error: all goroutines are asleep - deadlock!
为什么全局 db 变量仍是 nil 却不报错
典型遮蔽：你在 a.go 的 main() 或某个 init() 里写了 db, err := sql.Open(...)，这行用 := 声明了一个**局部变量 db**，包级 var db *sql.DB 根本没被赋值，始终为 nil。
- 后续
b.go直接调db.Query()→ panic:nil pointer dereference - 本地测试可能“侥幸”通过（比如只跑单个文件），CI 或线上环境必崩
- 编译不报错，运行时才暴露，且堆栈指向使用点而非初始化点，排查成本高
怎样安全初始化连接池（避开 init 的三个硬性条件）
只要违反任意一条，就必须移出 init：
- 涉及网络 I/O（
Ping、Connect、Auth）→ 改到main()开头或首个 handler 入口 - 依赖其他包状态（如配置未加载、log 未设置）→ 改用显式函数，按需顺序调用
- 需要错误恢复或日志记录 →
init中 panic 无法捕获，必须交由应用层处理
推荐做法：var UserDB *gorm.DB（初始 nil），提供 func SetupUserDB() error，内部用 sync.Once.Do 包裹 gorm.Open 和 Ping，并在 main() 中显式调用。注意：别在 init 里调 sync.Once.Do —— 它安全，但时机仍错。
DSN 与驱动名不匹配导致的静默卡死
现象是启动后卡几秒，然后报 invalid connection 或直接 panic，但无具体错误堆栈。大概率是 DSN 和驱动注册对不上：
- import _ "github.com/go-sql-driver/mysql"，但 DSN 写成
postgres://...→ 应该用pgx驱动 -
sql.Open("postgres", dsn)报错？实际应为sql.Open("pgx", dsn) - GORM 中用
mysql.New()却配了 PostgreSQL 的 DSN，不会编译失败，但第一次Create就 panic
验证方法：在初始化函数里加一行 log.Printf("connecting to %s with driver %s", dsn, driverName)，确保两者严格对应。
真正危险的不是“连接断开”，而是你根本不知道连接压根没建起来——所有看似健壮的重试、超时、健康检查逻辑，在 init 阶段全失效。把初始化从隐式拖拽变成显式控制，才是稳定服务的第一步。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
