GORM在电商项目中需精细配置：AutoMigrate不修正类型冲突，关联需显式Preload，事务内必须用tx对象并加锁，上线须关闭LogMode且避免SingularTable。
直接上手电商项目时，GORM不是“开箱即用”的魔法盒——它需要你明确表结构意图、控制迁移节奏、规避默认行为带来的隐性冲突。很多团队卡在 AutoMigrate 之后字段没生效、关联查不到数据、或上线后突然慢查询，根源往往不在SQL写得对不对，而在模型定义和数据库连接配置的细节里。
为什么 db.AutoMigrate(&User{}) 不一定创建出你想要的字段
GORM 的 AutoMigrate 只对比 Go struct 标签和当前表结构，不会主动修正已存在但类型/约束不匹配的列。比如你最初定义 Price string，后来改成 Price float64，AutoMigrate 不会改列类型，也不会报错，只是跳过。
- 真正生效的字段必须带有效 GORM 标签，例如
gorm:"size:255;index"，空标签或拼写错误（如grom）会被忽略 -
gorm.Model自带ID、CreatedAt、UpdatedAt、DeletedAt，若业务要求无软删除，得显式禁用：gorm:"not null"+ 手动移除DeletedAt字段 - MySQL 严格模式下，
NOT NULL字段没设默认值且没传值，插入会直接报Error 1364: Field doesn't have a default value
关联查询时 Product.Category 返回 nil 的常见原因
GORM 的预加载（Preload）和内联（Joins）不是自动开启的。即使模型里写了 Category Category `gorm:"ForeignKey:CategoryID"`，不做显式加载，Category 字段永远是零值。
- 用
db.Preload("Category").First(&product)才能拿到关联结构体；漏掉Preload就只查主表 -
ForeignKey标签名必须和外键字段名完全一致（注意大小写），比如结构体字段叫CategoryID，标签就得写ForeignKey:CategoryID，写成category_id就失效 - 如果
Category表本身没数据，或CategoryID值为 0，Preload后仍是 nil —— 这不是 bug，是预期行为
并发下单场景下，gorm.Transaction 容易被忽略的关键点
电商核心链路（如减库存+生成订单）必须事务包裹，但仅用 db.Transaction(func(tx *gorm.DB) error { ... }) 不够。
- 事务内所有操作必须用传入的
tx对象，写成db.First()就脱离事务，变成独立连接操作 - MySQL 默认隔离级别是
REPEATABLE READ，高并发下可能出现幻读；库存扣减建议加SELECT ... FOR UPDATE，GORM 写法是：tx.Clauses(clause.Locking{Strength: "UPDATE"}).Where("id = ?", pid).First(&product) - 别在事务里调用外部 HTTP 请求或耗时逻辑，超时会导致连接池阻塞，
SetMaxOpenConns再大也扛不住
线上环境 db.LogMode(true) 必须关掉
开发时打开日志方便调试，但上线后每条 SQL 都走 fmt.Sprintf 和 I/O 输出，实测 QPS 下降 30%+，且日志刷屏掩盖真正错误。
更稳妥的做法是在初始化时根据 Gin 模式判断：if gin.Mode() != gin.ReleaseMode { db.LogMode(true) }。另外，db.SingularTable(true) 虽然省去复数转换，但和主流 MySQL 命名习惯（users、products）冲突，后期对接 BI 工具或 DBA 审计时容易引发歧义——这个开关看似省事，实际增加了协作成本。
