Init中初始化数据库连接池易断连，因init()单线程同步执行、不支持context超时控制与重试，且依赖顺序不确定，导致Ping失败即panic、环境变量无法fallback、首次Query才暴露连接错误，进而引发超时或连接耗尽。
Init里做数据库连接池初始化为什么容易断连
因为 init() 函数是单线程同步执行的，不支持任何阻塞等待或 goroutine 协作。如果你在 init() 中调用 sql.Open() 后立刻依赖 Ping() 验证连通性，而数据库还没就绪（比如容器启动慢、网络延迟、DNS 解析卡住），Ping() 就会超时失败——但更危险的是：你没法重试、没法加 context 控制、也没法记录详细错误上下文，最终表现为“初始化成功了，但后续所有查询都报 dial tcp: i/o timeout 或 connection refused”。
-
init()中不能用context.WithTimeout包裹Ping()，因为一旦超时 panic，整个包加载失败，错误堆栈只显示failed to initialize package xxx，看不出是哪个 host/port 不通 - 数据库连接字符串若含环境变量（如
getEnv("DB_HOST")），init()期间无法做 fallback 或 warn，出错即终止 - 多个包互相 import 时，
init()执行顺序不确定，可能 A 包的init()尝试用 B 包已声明但尚未初始化的*sql.DB，结果得到 nil 指针
sql.Open 返回后不 Ping 就直接赋值到全局变量的后果
很多代码写成这样：DB, _ = sql.Open("mysql", dsn)，然后直接在其他函数里用 DB.Query()。这看似省事，实则埋雷——sql.Open() 只校验参数合法性，不真正建连；第一次 Query() 时才尝试拨号，此时错误才暴露，且发生在业务逻辑中，难以归因。
- 错误被抛到 handler 层，日志里看到的是
sql: connection is bad或driver: bad connection，而不是明确的初始化失败 - 如果并发高，大量 goroutine 同时触发首次连接，可能瞬间打爆数据库连接数限制（尤其
SetMaxOpenConns没设） - 没有主动设置
SetConnMaxLifetime和SetConnMaxIdleTime，旧连接不会自动淘汰，遇到数据库重启或网络闪断后，池子里残留大量 stale 连接，持续报错
如何安全地初始化并验证连接池可用性
把连接池创建和健康检查从 init() 拿出来，放到显式初始化函数里，在 main() 开头调用，并用带超时的 PingContext() 主动探测。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 初始化函数返回
error，让main()能决定是log.Fatal()还是重试（比如循环 3 次，每次间隔 2 秒） - 必须调用
db.SetMaxOpenConns()和db.SetMaxIdleConns()，否则默认最大打开连接数是 0（无限制），极易拖垮数据库 -
db.SetConnMaxLifetime(5 * time.Minute)和db.SetConnMaxIdleTime(5 * time.Minute)要配对使用，避免连接长期空闲后被中间件（如 RDS Proxy、HAProxy）静默断开 - 验证连通性时用
ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)，不是裸调db.Ping()
应用退出前 Close() 为什么有时不生效
DB.Close() 是非阻塞的，它只是标记连接池关闭、拒绝新请求，然后异步关闭空闲连接。如果程序在调用 Close() 后立刻退出（比如没加 time.Sleep 或没等 goroutine 结束），部分连接可能来不及清理，表现为数据库侧仍有残留连接，或日志里出现 connection reset by peer。
立即学习“go语言免费学习笔记（深入）”；
- 不要只靠
defer DB.Close()，尤其当main()里还启了其他长期 goroutine（如定时任务、后台监听）时，defer在main()返回时就执行了，但那些 goroutine 还在用DB - 正确做法是：用
context.WithCancel控制整个服务生命周期，DB.Close()放在所有依赖它的 goroutine 停止之后 - 如果用了
sync.WaitGroup等待子 goroutine，DB.Close()必须在wg.Wait()之后，否则可能有 goroutine 正在执行Query()时被中断 - 某些云数据库（如 AWS RDS）要求连接必须显式
Close()才能释放许可，漏掉会导致后续部署失败
连接池不是“初始化完就一劳永逸”的东西，它的生命周期要和应用进程对齐，初始化时机、健康检查方式、关闭顺序，三者缺一不可。最容易被忽略的是：别让 init() 承担本该由 main() 决策的责任。
