Gin 与 GORM 结合的关键是安全依赖注入而非全局变量或重复初始化：应在 main 启动时单例初始化 gorm.DB，通过构造函数逐层注入 Repository/Logic 层，Handler 仅调用业务方法；事务由 Logic 层统一控制，Repository 方法须接收 gorm.DB 参数以支持事务上下文；生产禁用 AutoMigrate，连接池需配 SetMaxOpenConns、SetConnMaxLifetime 等参数防失效连接。
直接上结论：Gin 本身不处理数据库，GORM 也不依赖 Gin；二者结合的关键不是“怎么连”，而是“怎么把 gorm.DB 安全、可测、可维护地注入到 Handler 里”。硬写全局变量或每次在 Handler 里重开连接，项目跑两周就难改难测。
为什么不能在 Handler 里直接调用 gorm.Open()
常见错误现象：API 响应越来越慢，偶尔 panic 报 too many connections，测试时 DB 连接泄漏导致 CI 失败。
- 每次
gorm.Open()都新建一个连接池，不是复用已有连接 - 没调用
db.Close()（而且不该在 Handler 里关）会导致连接堆积 - 无法对 DB 操作做单元测试——你没法 mock 一个现场 new 出来的
*gorm.DB - Gin 的并发模型下，多个 goroutine 同时执行
gorm.Open()可能触发竞态（尤其带日志配置时）
gorm.DB 应该作为依赖传入，而不是全局变量
正确做法是把 *gorm.DB 实例初始化好后，通过构造函数或依赖注入容器交给 repository 层，再逐层向上透传。这不是“多此一举”，是避免后期重构成本爆炸的底线。
- Handler 层只接收已初始化好的
logic.UserLogic，不碰gorm.DB - Logic 层接收
*repository.UserRepo，也不持有 DB 实例 - Repository 层才真正持有
db *gorm.DB字段，并只在这里调用db.Create()、db.First()等 - main.go 中统一调用
config.InitDatabase()，返回*gorm.DB，再构建各层实例
事务必须由 Logic 层控制，不能放在 Repository 或 Handler
比如用户充值要扣余额 + 记流水，两个操作必须原子性。如果把 db.Transaction() 放在 Repository 里，你就无法跨多个 Repo 协同事务；如果放在 Handler，业务逻辑就和 HTTP 细节混在一起了。
立即学习“go语言免费学习笔记（深入）”；
- Logic 方法签名应显式支持传入
*gorm.DB（如func (l *UserLogic) Recharge(tx *gorm.DB, userID uint, amount int64) error） - Handler 调用前先开启事务：
err := db.Transaction(func(tx *gorm.DB) error { return logic.Recharge(tx, ...) }) - Repository 方法需接受
*gorm.DB参数（而非固定用成员字段），否则无法接入事务上下文 - 别用
db.Session(&gorm.Session{New: true})伪造事务——它不提供回滚能力，只是隔离 scope
AutoMigrate 不该出现在生产启动流程中
开发阶段用 db.AutoMigrate(&User{}) 很方便，但上线后直接运行会带来风险：字段删了、类型改了、索引加了，AutoMigrate 可能静默失败或破坏数据。
- 只在本地开发或测试环境启用
AutoMigrate - 生产环境必须用 SQL 迁移脚本（如
golang-migrate），人工 review + 执行 - 如果坚持用 GORM 迁移，至少加
if os.Getenv("ENV") == "dev" { db.AutoMigrate(...) } -
AutoMigrate不会删除字段或表，只增不减——这容易掩盖 schema drift 问题
最常被忽略的其实是连接池配置。很多人只设 SetMaxOpenConns(100)，却忘了 SetConnMaxLifetime(1h) —— MySQL 默认 wait_timeout 是 8 小时，但 Kubernetes 下 Pod 重启更频繁，不设 lifetime 容易拿到失效连接。这个值必须比数据库侧的 timeout 小至少 5 分钟。
