定时任务中反复调用gorm.Open()会拖垮数据库，因其每次新建sql.DB实例并独占连接池，导致MySQL连接数超限；正确做法是在启动时初始化可复用的gorm.DB，并合理配置连接池参数、避免运行时重连或混用多数据源。
定时任务里反复gorm.Open()会直接拖垮数据库
不是“定时任务特殊”，而是它常被写成独立 goroutine 或 cron job，开发者容易忽略连接生命周期，每次执行都 gorm.Open() —— 这等于为每次任务新建一个 *sql.DB 实例，每个实例带独立连接池。哪怕每分钟跑一次，10 个任务并行就可能打开上百个空闲连接，MySQL 的 max_connections 很快被打满，报错 ERROR 1040: Too many connections。
根本原因：GORM 的 *gorm.DB 是并发安全的、可长期复用的句柄，不是“用完即弃”的临时对象。定时任务和 HTTP handler 一样，该共享同一个初始化好的实例。
- 别在任务函数里调
gorm.Open()，哪怕只调一次也错——它应该在应用启动时完成 - 如果任务逻辑分散在多个包，用包级变量或依赖注入传入已初始化的
*gorm.DB，不要让每个任务自己“找 DB” - 用
db.Session(&gorm.Session{NewDB: true})仅当需要隔离事务或上下文（比如日志写入不想被主事务回滚），但 Session 本身不创建新连接池
连接池参数必须在初始化后立刻设置，不能靠默认值
很多人写了 gorm.Open(...) 就以为完事了，其实 gorm.Config 完全不控制连接池，底层 *sql.DB 的参数仍保持极小默认值：MaxIdleConns=2、MaxOpenConns=0（无上限，但实际受系统文件描述符限制）。
定时任务往往短平快，连接来不及复用就被回收，若 SetConnMaxIdleTime 太短（如 5 秒），刚建好的空闲连接下一秒就被关，下次任务又得重连，白白增加握手开销。
- 必须紧接着
gorm.Open()调用db.DB().SetMaxOpenConns(30)和db.DB().SetMaxIdleConns(10)，数值按任务 QPS 和数据库规格调整，别硬写死 -
SetConnMaxLifetime(30 * time.Minute)和SetConnMaxIdleTime(10 * time.Minute)要配对设：前者防 MySQLwait_timeout中断长连接，后者确保空闲连接不过期太快 - 用
db.DB().Stats()在任务前后打日志，观察OpenConnections和InUse是否稳定，避免“看似没报错，实则连接疯涨”
定时任务失败时，别用 db.Error 触发“重连”
常见误操作：任务里执行 db.First(&u) 失败，看到 db.Error != nil 就 panic 后重试 + 新建 gorm.DB。这完全违背连接池设计初衷。
GORM 的 db.Error 是操作级错误，可能是记录不存在、字段类型不匹配、甚至网络超时包装后的通用 error，**它不表示连接已断**。盲目重连只会让连接数雪崩。
- 真正要捕获的是驱动原生错误：MySQL 看
*mysql.MySQLError.Number()是否为 2002/2013/1040；PostgreSQL 看*pq.Error.Code是否以"08"开头 - 任务里该做的是重试逻辑（如指数退避），而不是重建连接池——连接池自己会处理坏连接的剔除与新建
- 如果任务涉及跨库或长时间休眠（如每小时跑一次），可在执行前加
db.DB().Ping()做轻量健康检查，但别滥用，避免增加无效心跳
多数据源定时任务必须分池管理，不能混用
如果你有主库 + 日志库 + 统计库，且各自有定时任务，常见错误是只初始化一个 *gorm.DB，然后靠改 DSN 切换——*gorm.DB 是不可变的，DSN 绑定在底层 *sql.DB 创建时，运行时修改无效，还可能 panic。
每个数据源必须独立 gorm.Open()，并单独配置连接池参数。尤其注意：不同库负载差异大，日志库可能每秒写万条，而统计库每小时才跑一次聚合，它们的 MaxOpenConns 完全不该一样。
- 用结构体或 map 区分实例，比如
type DBs struct { Primary *gorm.DB; Log *gorm.DB }，避免命名混淆 - 日志类任务建议开启
PrepareStmt: false（关闭预编译），减少首次执行延迟；统计类任务可开PrepareStmt: true加速重复查询 - 事务无法跨数据源，
db.Transaction()只作用于单个实例——别指望一个事务同时写主库和日志库，得拆成两步 + 补偿逻辑
连接池不是“设了就完事”的开关，它和定时任务的执行频率、失败恢复方式、多源隔离粒度深度耦合。最容易被跳过的其实是 db.DB().Stats() 的日常观测——没有监控的连接池，就像没装仪表盘的跑车。
