gorm.DB.Close() 是唯一正确的关闭方式，它会优雅拒绝新请求并等待活跃查询完成后再释放底层 *sql.DB 的所有连接和 goroutine，必须在应用退出前且仅调用一次。
gorm.DB.Close() 是唯一正确的关闭方式
调用 db.Close() 才会真正释放底层 *sql.DB 的所有连接和 goroutine，其他任何操作（比如只清空变量、让 db 出作用域、或只调 db.Session()）都不起效。不显式 Close，进程退出前连接可能一直挂着，尤其在 CLI 工具、测试或短生命周期服务中容易残留连接。
常见错误现象：lsof -i :3306 仍能看到大量 ESTABLISHED 连接；MySQL 的 SHOW PROCESSLIST 中出现长时间 SLEEP 的连接；k8s pod 重启后旧连接未断开，新实例又建连，快速触达 max_connections 上限。
-
db.Close()必须在应用退出前调用一次，且仅一次 —— 多次调用会 panic 报sql: database is closed - 不要在 handler 或 goroutine 里调
db.Close()，它不是按请求关闭的，而是全局收尾动作 - 若用
defer db.Close()，确保 defer 发生在 main goroutine 退出路径上（例如 main 函数末尾），而非某个临时函数里
Close 前必须等所有活跃查询结束
db.Close() 是“优雅关闭”：它会拒绝新请求，但等待正在执行的查询完成后再真正释放资源。如果此时还有未完成的 db.First()、db.Transaction() 或长事务没 Commit/Rollback，Close() 会阻塞，甚至导致进程无法退出。
使用场景：CLI 工具跑完即关、FaaS 函数执行完毕、测试用例 tearDown 阶段。
- 确保所有
db.Transaction()显式调用了tx.Commit()或tx.Rollback() - 避免在 goroutine 中启动未同步的查询（如
go db.Create(&u)后没 wait），否则Close()可能提前返回，而 goroutine 仍在用已关闭的 db - 若需强制中断，可配合 context.WithTimeout 启动查询，但
Close()本身不接受 context
别混淆 Close 和连接池参数重置
有人误以为调 db.DB().SetMaxOpenConns(0) 或把 MaxIdleConns 设为 0 就等于“关闭”，其实这只是限制新连接获取，池中已有连接仍存活，且不会触发清理逻辑。
这些操作对释放资源无效，反而可能引发 panic 或行为异常：
-
db.DB().SetMaxOpenConns(0)→ 新查询直接报sql: MaxOpenConns is 0 -
db.DB().SetMaxIdleConns(0)→ 空闲连接用完即销毁，但活跃连接照常，且下次需要时仍会新建 - 修改
SetConnMaxLifetime或SetConnMaxIdleTime只影响后续连接行为，不回收当前已建连接
测试/命令行场景下最容易漏掉 Close
Web 服务通常靠进程终止间接释放，但 CLI 工具、migration 脚本、单元测试中的 gorm.Open() 很容易被当成“用完即弃”，结果每次执行都悄悄建一批连接，反复运行几次就耗尽本地 MySQL 的 max_connections（默认 151）。
典型误配：
- 测试文件里
func TestUser(t *testing.T) { db, _ := gorm.Open(...) }—— 没 Close，test 跑完连接还在 - migration 工具每次执行都
gorm.Open()+AutoMigrate()+ 直接 exit —— 连接未释放 - main 函数里开了 db，但没 defer 或没放在 return 前，panic 或 os.Exit(0) 绕过了 Close
真正安全的做法：所有非 long-running 场景，只要调了 gorm.Open()，就必须有对应的 db.Close()，且保证它被执行到 —— 最好写在 main 函数最后一行，或用 os.Exit() 前显式调用。
