gorm.Open() 必须全局只调用一次，否则导致连接池泄漏和文件描述符耗尽；应启动时初始化单例，显式配置 SetMaxOpenConns、SetMaxIdleConns 和 SetConnMaxLifetime；并发读取需用主键/时间戳游标分片，禁用 Offset 分页。
gorm.Open() 必须全局只调用一次，否则连接池泄漏
反复在 goroutine 或 HTTP handler 里调 gorm.Open()，表面看能“拿到新连接”，实则每次都在新建 *sql.DB 实例——旧的连接池不会自动关闭，db.Close() 又常被忽略，最终导致文件描述符耗尽、MySQL 报 Too many connections。这不是并发问题，是资源管理失控。
正确做法是应用启动时初始化一次，全局复用同一个 *gorm.DB 实例：
- 用包级变量 +
sync.Once（比init()更可控，支持错误返回） - 或注入到结构体字段（如
type Service struct { DB *gorm.DB }），由依赖注入容器统一管理生命周期 - 切勿在 handler 内写
db, _ := gorm.Open(...)
SetMaxOpenConns 和 SetMaxIdleConns 必须显式设，且不能乱配
SetMaxOpenConns 默认是 0（无上限），上线后并发稍高，MySQL 的 max_connections 很快打满；SetMaxIdleConns 若大于 SetMaxOpenConns，Go 1.12+ 会 panic："max idle conns exceeds max open conns"。
推荐配置（以 MySQL 为例）：
- 先查数据库：执行
SHOW VARIABLES LIKE 'max_connections'，假设返回 200 -
db.DB().SetMaxOpenConns(120)（取 60%～80%，留余量给备份、监控等其他服务） -
db.DB().SetMaxIdleConns(60)（设为SetMaxOpenConns的 1/2） -
db.DB().SetConnMaxLifetime(2 * time.Minute)（适配云数据库主备切换，避免 NAT 断连）
协程并发读取必须用游标分片，禁用 Offset 分页
GORM 本身不支持“多通道分片分页读取”。强行开多个 goroutine 并发跑 db.Limit().Offset()，会导致：
- 每个查询都重复扫描前 N 行，IO 和 CPU 翻倍
- 期间有新数据插入时，记录可能重复或丢失（尤其按时间排序）
-
*gorm.DB实例非线程安全，共享实例调Where()、Order()会互相污染条件 -
Count()和分页查询不在同一事务快照下，总数与实际不一致
真正可行的是基于主键或时间戳的游标分片：
- 先查全表
MIN(id)和MAX(id) - 按步长（如 10000）切区间：
[minID, minID+9999]、[minID+10000, minID+19999]… - 每个 goroutine 使用独立 session：
db.Session(&gorm.Session{NewDB: true}) - 查询条件互斥：用
WHERE id >= ? AND id ，右边界必须用 <code>
db.Ping() 是启动必检项，不是可选动作
gorm.Open() 只是初始化连接池结构，不建真实连接。很多服务日志写着 “DB initialized”，其实第一笔查询才真正拨号——这时候网络不通、密码错、DNS 解析失败，全堆在首请求上，导致线上首屏白屏。
务必在初始化后立即调用：
if err := db.Ping(); err != nil { log.Fatal("DB ping failed:", err) }- 别依赖
defer db.Close()：它只关底层*sql.DB，但 GORM 实例仍持有已失效指针 - 连接池参数（如
SetMaxOpenConns）必须在db.Ping()前设置，否则无效
连接池和协程的配合难点不在“能不能并发”，而在“怎么让每个 goroutine 拿到确定、隔离、可预期的连接行为”——游标分片要自己切区间，连接参数要按数据库真实容量反推，SetConnMaxLifetime 和 SetMaxIdleConns 必须配对设，漏掉任意一环，线上就容易凌晨三点告警。
