gorm 初始化必须在 init 之外且只执行一次，使用全局 *gorm.db 实例；反复调用 gorm.open() 会创建多个连接池，导致连接耗尽、内存泄漏和事务失效。
大型项目中 GORM 的初始化必须放在 init 之外，且只执行一次
全局 *gorm.DB 实例不是线程不安全的——它本身就是并发安全的连接池句柄，但反复调用 gorm.Open() 会创建多个独立连接池，导致连接耗尽、内存泄漏、事务失效。错误做法是每个 handler 或 service 都自己 Open 一次；正确路径是在项目启动早期（如 utils.InitMysql() 或 dal/init.go）完成初始化，并导出为包级变量。
常见错误现象包括：
- 数据库报错
too many connections，即使设置了MaxOpenConns - 事务内查询无法看到未提交变更（因用了不同 DB 实例）
- 日志里出现多条重复的
Connected to MySQL提示
实操建议：
- 在
dal/目录下新建mysql.go，定义var DB *gorm.DB和func Init() error -
Init()中使用gorm.Config{PrepareStmt: true, Logger: newLogger()}等生产必需配置 - 避免在
init()函数里初始化 DB：它不可控、无法返回 error、不利于测试和配置注入 - 主函数中显式调用
dal.Init()，失败则os.Exit(1)
模型（models/）与数据访问层（dal/）必须物理分离
把 struct 定义和 CRUD 方法混在同一个文件里，会导致业务逻辑与数据操作强耦合，无法做单元测试、无法替换底层存储、也无法复用模型到 CLI 工具或离线任务中。
推荐结构：
-
models/user.go：仅含User结构体、TableName()、GORM 标签（如gorm:"type:varchar(64);uniqueIndex"） -
dal/user.go：含FindByEmail()、CreateWithTx()、UpdateStatus()等方法，接收*gorm.DB或context.Context - 绝不允许
models/包 importdal/或任何 DB 相关包
这样拆分后，service/user.go 可以依赖 models 和 dal，但不会被数据库细节污染；同时 dal 层可轻松接入 mock DB 进行测试。
internal/ 下的 dal 目录要支持多数据源与读写分离
当项目增长到需分库（如用户库、订单库）、读写分离或 sharding 时，硬编码单个 DB 变量会立刻成为瓶颈。此时不能靠改全局变量，而应抽象为可注册的数据源管理器。
实操要点：
- 在
internal/dal/下定义type DataSource string，如DSUserMaster、DSOrderSlave - 用
map[DataSource]*gorm.DB存储多个实例，通过GetDB(ds DataSource) *gorm.DB获取 - 所有 DAO 方法签名升级为
func (u *UserDAO) Create(ctx context.Context, db *gorm.DB, u *models.User) error，由调用方传入具体 DB 实例 - 避免在 DAO 内部调用
dal.GetDB(...)：这会让测试难以控制依赖，也阻碍事务跨库传播
这个设计看似多了一层，但能让你在上线前一周从容接入从库，而不用重写全部数据访问逻辑。
GORM 初始化时必须显式配置连接池与超时参数
默认的 *sql.DB 连接池参数极不适用于生产环境：MaxOpenConns=0（无上限）、MaxIdleConns=2、ConnMaxLifetime=0。这些值在高并发下极易引发连接堆积、DNS 解析失败、连接老化等隐性故障。
关键参数设置建议：
-
sqlDB, _ := DB.DB()后立即调用：sqlDB.SetMaxOpenConns(100)、sqlDB.SetMaxIdleConns(20)、sqlDB.SetConnMaxLifetime(60 * time.Second) -
gorm.Config中启用PrepareStmt: true（防 SQL 注入 + 提升预处理性能） - 开启慢查询日志：
logger.New(log.New(os.Stdout, "\r\n", 0), logger.Config{SlowThreshold: time.Millisecond * 200}) - 禁用全表日志：
logger.Default.LogMode(logger.Error)（开发可调为Info）
最容易被忽略的是 SetConnMaxLifetime：MySQL 默认 wait_timeout=28800 秒，但 Kubernetes 中 Pod 重启、LB 断连更频繁，设为 30–60 秒能主动淘汰陈旧连接，避免 invalid connection 报错反复出现。
