init中初始化db连接池会拖慢启动，因其强制预建连接、无法错误恢复且日志不可见；应移至main或首次调用时用sync.once按需初始化，并显式配置池参数。
为什么 init 里初始化 DB 连接池会拖慢启动
Go 程序启动时，init 函数执行完才进入 main，而 GORM 或 sql.DB 的连接池默认会在首次调用 Open 后立即预建多个空闲连接（如 GORM 默认 MaxOpenConns=10）。这些连接不是“懒连”，而是初始化即拨号、认证、握手——只要 gorm.Open 或 sql.Open 在 init 里被调用，整个服务就得卡住等满池建好，哪怕后续只用其中 1 个连接。
更糟的是：错误不报在 init，而是在第一次查询时才暴露，比如 "dial tcp: i/o timeout" 或 "invalid connection"，但此时 main 都没跑起来，日志可能还没接管，根本看不到上下文。
怎样让 DB 连接池真正“按需建立”
核心是把 gorm.Open / sql.Open 移出 init，改用显式函数 + sync.Once 控制首次调用时机。这不是“延迟加载”，而是把连接行为从“包加载期”挪到“业务首次需要时”。
- 定义一个导出变量，比如
var UserDB *gorm.DB，初始为nil - 提供
func SetupUserDB() error，内部用sync.Once.Do包裹gorm.Open调用，并赋值给UserDB - 在
main中显式调用SetupUserDB()，或在第一个 HTTP handler 里首次访问前检查非空 - 别在
init里调sync.Once.Do—— 它本身安全，但 init 阶段无法 recover 错误，且违背“控制权交还应用层”的原则
DSN 和驱动注册错位导致连接卡死
常见现象：程序启动后卡住几秒，然后报 "invalid connection" 或直接 panic，但没具体错误堆栈。大概率是 DSN 格式和驱动注册不匹配。
例如：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 代码写了
import _ "github.com/go-sql-driver/mysql"，但 DSN 却是postgres://... - 或用了
pgx/v5驱动，却传了sql.Open("postgres", ...)—— 实际应为sql.Open("pgx", ...) - GORM 里传错
gorm.Dialector：用mysql.New()却配了 PostgreSQL 的 DSN，不会编译报错，但第一次Create就失败
验证方法：在 SetupUserDB 里加一行 log.Printf("connecting to %s with driver %s", dsn, driverName)，确保两者对得上。
连接池参数必须显式覆盖默认值
即使你把 Open 移出了 init，GORM 和 sql.DB 的默认池参数仍可能预分配过多资源。冷启动内存虚高、首请求延迟高，往往就源于此。
务必显式设置：
-
db.SetMaxOpenConns(5)（别用默认 10 或 0） -
db.SetMaxIdleConns(2)（避免空闲连接长期占着 socket） -
db.SetConnMaxLifetime(30 * time.Minute)（防长连接老化） - GORM v2+ 还要调
db.Config.ConnPool = &sql.DB{...}才能生效，不能只设Open返回的实例
这些调用必须放在 SetupUserDB 函数里、gorm.Open 之后，且不能漏 —— 因为连接池结构体在 Open 时已创建，后续再设只是更新字段，不重建底层资源。
最易被忽略的一点：第三方包的空白导入（如 import _ "github.com/lib/pq"）会触发其 init，而某些驱动的 init 会悄悄注册全局回调或初始化默认 logger，间接影响你的 DB 初始化行为。上线前用 go list -deps your/main/pkg | grep pq 检查隐式依赖链。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
