init中初始化连接池极易导致启动卡死或panic，因其执行同步阻塞I/O（如db.Ping）且无法被context中断；变量遮蔽更会使全局db为nil，引发后续nil pointer dereference。
init 里初始化连接池，程序大概率会在启动时卡死或 panic，而不是“断开隐患”——它根本活不到需要断开的那一刻。
为什么 init 中调用 sql.Open 或 redis.NewClient 就可能失败
很多人以为 sql.Open 是“建连”，其实它只是返回一个 *sql.DB 句柄，不真正拨号；但紧接着在 init 里调 db.Ping() 或 client.Ping(ctx)，就触发了同步阻塞 I/O：
-
db.Ping()会尝试建立并复用一个连接，网络不可达、DNS 解析慢、防火墙拦截都会让整个init卡住数秒甚至超时 - Go 运行时在
init阶段禁止新 goroutine 调度，所以context.WithTimeout+Ping也无法优雅中断——ctx.Done()永远不会被 select 到 - 若连接池库内部用了
sync.WaitGroup或 channel 等待（比如某些封装层），直接触发fatal error: all goroutines are asleep - deadlock!
init 里创建连接池后，全局变量仍为 nil 的真实原因
典型错误不是连接池没建好，而是包级变量根本没被赋值成功：
- 在
a.go的main()或某个init()函数里写db, err := sql.Open(...)→:=声明的是局部变量，包级var db *sql.DB仍是nil - 后续其他文件（如
b.go）直接用db.Query(...)，运行时 panic：nil pointer dereference - 这种 bug 在本地测试可能“碰巧”不暴露（比如测试时只跑单个文件），上线后必崩
连接池初始化必须避开 init 的三个硬性条件
只要违反任意一条，就该立刻移出 init：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 需要访问环境变量（如
os.Getenv("DB_URL")）→init执行时flag.Parse()还没跑，变量可能为空 - 依赖其他包已初始化的状态（如日志器
log.Info、配置中心客户端）→ 跨包init顺序不保证，可能 panic - 需要错误处理和重试逻辑（比如连接失败后 sleep 1s 再试）→
init里panic就是进程退出，无法 fallback
安全初始化连接池的唯一推荐路径
把连接池创建下沉到显式函数，由 main() 控制时机和错误流：
// db/db.go
var instance *sql.DB
<p>func Setup(dsn string) error {
db, err := sql.Open("mysql", dsn)
if err != nil {
return err
}
if err = db.Ping(); err != nil {
return err
}
instance = db
return nil
}</p><p>func Get() *sql.DB { return instance }
-
Setup()返回error，可在main()中log.Fatal()或降级启动 -
Get()可加空指针检查（生产环境建议）：if instance == nil { panic("db not initialized") } - 如果真要懒加载，用
sync.Once包一层，但首次调用仍需在业务路径中，而非init
真正容易被忽略的点：第三方连接池库（比如 go-redis/redis/v9）的 init 函数本身不建连，但它可能注册了全局钩子或默认选项；如果你又在自己的 init 里调它的构造函数，等于在两个不可控的隐式阶段叠加副作用——排查时根本分不清是哪个 init 卡住的。
