应避免在init中执行网络连接，因其会阻塞程序启动、无法超时、日志不可见且错误难定位；推荐改用sync.once按需初始化并显式处理错误。
别在 init 里做任何网络连接——它不会“连不上”，而是让你的程序根本起不来。
为什么 init 中调用 http.Get 或 db.Ping 会卡死
Go 的 init 函数是单线程同步执行的，运行时在此阶段禁止 goroutine 调度。一旦你在 init 里触发网络 I/O（比如 http.Get、redis.Client.Ping、甚至 sql.DB.Ping），就等于要求整个程序停在那儿等 DNS 解析、TCP 握手、TLS 协商——没有任何超时、无法被 context 中断，也看不到错误日志（因为日志系统可能还没初始化）。
- 现象：服务启动后卡住 5–30 秒，然后直接 panic 或静默退出，堆栈只显示
runtime.init相关帧 - 根本原因：不是连接“失败”，而是阻塞在系统调用上，且 Go 运行时此时不调度任何其他 goroutine 来处理超时或重试
- 特别危险的是
sync.WaitGroup.Wait或无缓冲 channel receive —— 它们依赖调度器，但在init中必死锁
sql.Open 和 gorm.Open 不等于“已连上”，但 init 里调它们仍很危险
sql.Open 和 gorm.Open 本身只是构造句柄，不立即拨号；但很多人会在 init 里紧接着调 db.Ping() 或 db.Exec("SELECT 1") 来“预热”，这就踩中雷区。更隐蔽的是 GORM 默认启用 MaxOpenConns=10，首次调用 Query 时会同步建满空闲连接——如果这个“首次”发生在某个 handler 里，那问题还在业务层；但如果在 init 里提前触发了任何查询，池子就立刻全量拨号。
- DSN 和驱动名不匹配（如用
github.com/go-sql-driver/mysql却配postgres://）不会编译报错，但第一次真实操作时才 panic，且堆栈难定位 - 建议在真正打开连接前加日志：
log.Printf("opening %s with driver %q", dsn, driverName)，确保两者对得上 - 显式配置池参数比依赖默认值更可控：
db.SetMaxOpenConns(5)、db.SetMaxIdleConns(2)
用 sync.Once 替代 init 做连接初始化是否安全
安全，而且推荐。它把“首次连接”从“包加载期”移到“业务需要时”，既避开 init 的调度限制，又保留单次执行语义。
- 定义包级变量：
var UserDB *gorm.DB（初始为nil） - 写初始化函数：
func SetupUserDB() error，内部用sync.Once.Do包裹gorm.Open并赋值 - 在
main开头或第一个 HTTP handler 入口处显式调用SetupUserDB()，并检查返回 error - 不要在
init里调sync.Once.Do——它虽安全，但违背“控制权交还应用层”的原则，且错误仍无法 recover
全局变量被遮蔽导致 nil pointer dereference
这是线上最常复现又最难 debug 的问题之一：你以为在 init 里初始化了 db，结果别的文件用的时候 panic。大概率是因为写了 db, err := sql.Open(...)——这个 := 声明的是局部变量，包级 var db *sql.DB 仍是 nil。
- 现象：
panic: runtime error: invalid memory address or nil pointer dereference，堆栈指向db.Query等调用 - 验证方法：在初始化函数里打印
fmt.Printf("db = %+v\n", db)，确认它非 nil 再继续 - 更稳妥的做法是返回值校验 + 显式 panic 或 log.Fatal：比如
if UserDB == nil { log.Fatal("failed to setup UserDB") }
真正麻烦的从来不是“连不上数据库”，而是你根本不知道它在哪一步、以什么方式、为什么没连上——init 把所有错误都藏在启动黑盒里。把连接逻辑移出来，哪怕多写两行 if err != nil，也比靠运气上线强。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
