不应在init中调用gorm.open或sql.open，因其会同步预建连接池导致启动卡顿、错误不可见且无法恢复；应改用sync.once配合显式初始化函数，在main或首次调用时按需建立并可控处理错误。
别在 init 里调 gorm.Open 或 sql.Open —— 启动会卡住，错误还看不见，连接池根本不是“懒的”，而是“急的”。
为什么 init 里开 DB 会拖慢启动甚至卡死
Go 程序启动时，init 函数必须全部执行完才能进 main。而 gorm.Open 或 sql.Open 默认会立即尝试建立多个空闲连接（比如 GORM 的 MaxOpenConns=10），这不是“建好一个连一个”，而是同步拨号、握手、认证——哪怕你后续只用 1 个连接，也得等满池建完。
更麻烦的是：这些连接失败不会在 init 报错，而是在第一次 Create 或 First 时才暴露，比如 "dial tcp: i/o timeout" 或 "invalid connection"，但此时日志系统可能还没接管，堆栈也看不到上下文。
-
init阶段无法recover错误，panic 直接终止进程 - 连接池参数（如
SetMaxOpenConns）若在init后设置，已建连接不受影响，配置实际失效 - DSN 和驱动不匹配（如用
mysql驱动却传postgres://）也会卡在这一步，无明确提示
sync.Once + 显式函数才是真正的按需初始化
把连接行为从“包加载期”挪到“业务首次需要时”，控制权交还应用层。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 定义导出变量：
var UserDB *gorm.DB，初始为nil - 写初始化函数：
func SetupUserDB() error，内部用sync.Once.Do包裹gorm.Open调用，并赋值给UserDB - 在
main开头显式调用SetupUserDB()，或在第一个 HTTP handler 中检查UserDB == nil后触发 - 别在
init里调sync.Once.Do—— 它本身安全，但违背“错误可捕获、时机可掌控”的原则
DSN 和驱动注册不匹配导致的静默卡顿
现象是启动后卡几秒，然后报 "invalid connection" 或直接 panic，没堆栈。大概率是 DSN 格式和驱动注册对不上。
- 写了
import _ "github.com/go-sql-driver/mysql"，但 DSN 是postgres://... - 用了
pgx/v5驱动，却调sql.Open("postgres", ...)—— 正确应为sql.Open("pgx", ...) - GORM 中传了
mysql.New()，但 DSN 是 PostgreSQL 地址，编译不报错，第一次Create就失败 - 验证方法：在
SetupUserDB里加一行log.Printf("connecting to %s with driver %s", dsn, driverName)，确保两者一致
多数据库场景下更不能依赖 init
多个 DB 实例共存时，init 的执行顺序不可控，且无法区分错误来源。比如 UserDB 初始化失败，不该让 LogDB 也跟着失败或跳过。
- 每个 DB 应有独立初始化函数（如
SetupUserDB()、SetupLogDB()），由main按需调用并分别处理错误 - 若用依赖注入（如 fx 或 wire），需为每个
*gorm.DB绑定唯一类型名（如type UserDB *gorm.DB），否则容器会混淆实例 - 避免跨包在
init中互相调用导出函数（如log.Info），可能因初始化顺序未完成而访问零值
真正难处理的不是“怎么连上”，而是“连不上时谁来负责记录、重试、降级”。把 DB 初始化移出 init，等于把错误处理、日志埋点、超时控制这些关键逻辑，从黑盒里拽出来放在阳光下——这才是可控性的起点。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
