GORM在无服务器环境必须每次调用gorm.Open()，因平台沙箱进程不共享全局变量、冷启动时连接已失效，且连接池无法跨请求复用。
无服务器环境（如 AWS Lambda、Cloudflare Workers、Vercel Edge Functions）中，GORM 的连接池不能复用，强行复用会导致冷启动失败、连接泄漏或“database is closed”错误——这不是配置问题，是执行模型冲突。
为什么 gorm.Open() 在函数计算里必须每次重调？
无服务器平台每次请求可能分配全新沙箱进程，全局变量不跨调用持久化。你写在包级的 var db *gorm.DB 在第二次调用时大概率是 nil 或已失效指针。
- Lambda 执行完会冻结容器，但底层 TCP 连接不会自动保持；下次唤醒时旧连接基本已断，
db.Ping()会直接报"i/o timeout"或"connection refused" - Cloudflare Workers 完全无持久内存，所有变量生命周期仅限单次 fetch handler，
init()函数甚至不会执行 - 试图在 handler 里缓存
*gorm.DB到闭包变量，看似“复用”，实则每次冷启动都新建连接池，而热启动时又无法保证连接健康 —— 最终表现为偶发性"invalid connection"
如何降低冷启动时的连接初始化开销？
不能省掉 gorm.Open()，但可以压缩它耗时并避免阻塞主线程：
- DSN 中去掉冗余参数：删掉
&timeout=30s&readTimeout=30s等，让连接建立更快；MySQL 推荐保留?charset=utf8mb4&parseTime=True&loc=Local，PostgreSQL 必须带?sslmode=disable - 禁用 GORM 日志：
&gorm.Config{SkipDefaultTransaction: true, Logger: logger.Default.LogMode(logger.Silent)}，避免日志 IO 拖慢初始化 - 不要调
db.AutoMigrate()或任何 Schema 操作 —— 这些必须在部署前完成，运行时执行会超时 - 若用 MySQL，驱动 DSN 加上
&multiStatements=true（仅当需批量执行），否则默认关闭，避免隐式解析开销
连接池参数在 serverless 里要不要设？
要设，但逻辑和常驻服务相反：不是为了“复用”，而是为了“及时释放”。
-
SetMaxOpenConns(1)是合理选择 —— 无服务器函数本质是单并发模型，开多个连接纯属浪费，还可能触发数据库连接数上限 -
SetMaxIdleConns(1)，且必须 ≤SetMaxOpenConns，否则 runtime panic -
SetConnMaxLifetime(30 * time.Second)：强制连接在 30 秒后关闭，避免被平台回收前残留无效连接 -
SetConnMaxIdleTime(10 * time.Second)：空闲 10 秒就关，防止 warm pool 里积压死连接
怎么判断一次请求里该不该重连？
别自己写重连逻辑。serverless 场景下，唯一可靠的“重连”就是让整个 handler 失败并重试 —— 但代价太高。更务实的做法是精准识别瞬时网络错误，并快速 fail fast：
- 对
result.Error做类型断言，只处理明确的连接层错误：*mysql.MySQLError的Number()== 2002 / 2013，或*pq.Error的Code[0:2] == "08" - 忽略
gorm.ErrRecordNotFound、1062 (duplicate entry)等业务错误 —— 它们不是连接问题，重连毫无意义 - 遇到
"dial tcp: i/o timeout"或"context deadline exceeded"，直接返回 503，由上游重试；不要捕获后 sleep 再重试，函数超时不可控 - 永远不要在 handler 里调
db.Close()—— 它会提前释放连接，后续同请求内其他 DB 操作必报"database is closed"
最易被忽略的一点：无服务器平台的“warm start”不等于“连接可用”。即使复用了容器，TCP 连接大概率已被中间网络设备（ALB、NAT 网关、RDS Proxy）静默断开。靠 Ping() 验证只是徒增延迟，真正有效的只有“用即检测”——把错误处理逻辑下沉到每条 db.First()、db.Create() 调用之后，而不是集中做一次健康检查。
