Lambda中每次调用新建GORM连接会导致MySQL连接数暴增和冷启动延迟飙升，根本原因是gorm.Open()每次创建全新连接池，而sql.DB连接池必须跨调用复用；正确做法是用sync.Once懒加载包级gorm.DB并配置SetMaxOpenConns、SetMaxIdleConns、SetConnMaxLifetime和关键的SetMaxIdleTime(1*time.Minute)。
为什么Lambda里每次调用都新建GORM连接会炸
不是GORM慢，是连接没复用——Lambda每个调用若都执行 gorm.Open()，就会为每次请求新建一套连接池，而AWS Lambda的执行环境可能被复用，也可能被回收。一旦连接池没被正确复用或关闭，MySQL/PostgreSQL服务端很快报 too many connections，且冷启动延迟飙升。
根本原因在于：GORM本身不持有连接，它依赖 *sql.DB；而 *sql.DB 的连接池必须跨调用生命周期存活，否则等于每秒新建销毁几十个TCP连接。
- 错误写法：在 handler 函数内调用
gorm.Open()或db, _ := gorm.Open(...) - 正确姿势：把
*gorm.DB声明为包级变量，在init()或首次 handler 调用时用sync.Once初始化 - 必须立刻拿到原生
*sql.DB并设参，否则默认SetMaxOpenConns(0)（无上限）+SetMaxIdleConns(2)（严重不足）
怎么让GORM连接池在Lambda里真正复用
Lambda执行环境可能复用，但不会保证复用同一实例；你不能依赖 init() 一定只跑一次（尤其在预置并发或多AZ部署下），所以得靠 sync.Once + 包级指针双重保险。
示例代码结构：
var (
db *gorm.DB
once sync.Once
)
<p>func getDB() <em>gorm.DB {
once.Do(func() {
dsn := os.Getenv("DB<em>DSN")
var err error
db, err = gorm.Open(mysql.Open(dsn), &gorm.Config{})
if err != nil {
panic(err)
}
sqlDB, </em> := db.DB()
sqlDB.SetMaxOpenConns(20) // Lambda并发通常不高，20够用
sqlDB.SetMaxIdleConns(10) // 避免反复建连
sqlDB.SetConnMaxLifetime(5 </em> time.Minute) // 防MySQL主动断连后重连风暴
sqlDB.SetMaxIdleTime(1 * time.Minute) // 空闲1分钟即释放，适配Lambda空闲回收
})
return db
}
注意：SetMaxIdleTime(1 * time.Minute) 比 SetConnMaxLifetime 更关键——它让空闲连接主动退出，避免 Lambda 执行环境被冻结前还攥着一堆“僵尸连接”。
Preload和Joins在Lambda里特别容易OOM
Lambda内存有限（常见128–1024MB），而 Preload("Orders.Items.Tags") 这种嵌套加载不做限制，一次查几百条主记录就可能拉下几十MB数据，直接触发 OUT_OF_MEMORY 错误。
- 禁用无条件
Preload：哪怕只查10个用户，Preload("Orders")也会全量扫订单表 - 改用
Joins+Select：字段可控、无反射开销、内存占用可预估 - 对关联结果强制分页或限流：比如
Preload("Orders", func(db *gorm.DB) *gorm.DB { return db.Limit(5) }) - 更彻底的方案：拆成两步查，先查主表ID，再用
IN查关联数据（注意MySQLIN参数上限）
冷启动时别碰数据库初始化
很多人把 gorm.Open() 放进 main()，以为“只执行一次”，但Lambda计费和超时从二进制加载完成就开始了——main() 里的任何I/O（包括连DB）都在冷启动窗口里，拖慢首字节时间，还可能超时失败。
真正安全的时机只有两个：
- 第一次 handler 调用时，用
sync.Once懒加载（推荐） - 用预置并发“预热”环境后，再触发一次 handler 完成初始化（需配合健康检查）
切记：不要在全局变量初始化时调用 db.Ping() 或 AutoMigrate()，它们都是阻塞I/O；AutoMigrate 应只在部署脚本或单独Migration函数中运行。
最后一点容易被忽略：Lambda的 /tmp 是唯一可写的本地路径，但GORM日志若写到文件，必须确保路径存在且有权限；更稳妥的做法是统一走 log.Printf，由Lambda日志系统接管。
