不能在 init 里调 gorm.open 或 sql.open，因其会阻塞启动、掩盖错误且无法恢复；应改用显式初始化函数配合 sync.once，在 main 中按需调用并传入配置。
别在 init 里调 gorm.open 或 sql.open，它会卡住启动、掩盖错误、且无法恢复。
为什么 init 里开 DB 连接池等于“自缚手脚”
Go 程序启动时，所有 init 函数必须全部执行完，才能进入 main。而 sql.Open 或 gorm.Open 默认会立即尝试建立 MaxOpenConns 个空闲连接（比如默认 10 个），不是“用时再连”，是“声明即拨号”。这意味着：程序得等满池建完、认证通过、握手成功，哪怕你后续只查一次库。
更麻烦的是，失败不发生在 init 阶段——Open 只返回 *sql.DB 和 error，但 error 常为 nil；真正报错（如 dial tcp: i/o timeout）要等到第一次 Query 或 Create，此时 main 还没跑起来，日志系统可能都未接管，错误直接被吞掉或 panic 在无人处。
怎样把 DB 初始化真正“按需化”
核心是把连接行为从“包加载期”移到“业务首次需要时”，用显式控制替代隐式触发：
- 定义一个导出变量，如
var UserDB *gorm.DB，初始值为nil - 写一个初始化函数，如
func SetupUserDB() error，内部用sync.Once.Do包裹gorm.Open调用，并赋值给UserDB - 在
main函数开头显式调用SetupUserDB()，或在第一个 HTTP handler 中检查UserDB == nil后再触发 - 别在
init里调sync.Once.Do——它本身安全，但 init 阶段无法 recover 错误，且违背“控制权交还应用层”的原则
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()但配了 PostgreSQL 的 DSN，编译不报错，但第一次Create就失败 - 验证方法：在
SetupUserDB里加一行log.Printf("connecting to %s with driver %s", dsn, driverName)，确保两者对得上
init 中看似安全、实则危险的“跨包依赖”
你以为只是引用了一个全局变量，比如 config.DBURL，但它所属包的 init 可能根本没跑——Go 不保证跨包变量初始化顺序，只保证“被依赖包先于依赖包”。如果 db 包 import 了 config，但 config 又间接 import 了 db（比如通过某个工具包的空白导入），就可能形成初始化环，导致 config.DBURL 还是空字符串，而 gorm.Open("") 会 panic。
这种问题往往只在特定构建环境或交叉编译时暴露，调试成本极高。最稳妥的做法，是切断直接依赖：用 func Init(cfg Config) 显式传参，把初始化时机完全收归 main 控制——而不是靠 init 猜顺序。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
