GORM与Gin配合完全可行，但多数人因数据库连接管理不当、结构体JSON标签缺失、GORM链式查询变量未初始化这三处导致线上静默失败。
直接上结论：GORM 和 Gin 配合用没问题，但多数人栽在连接管理、结构体标签和查询链路这三处——不是框架不行，是初始化和调用姿势不对。
数据库连接必须独立初始化，不能塞进 main.go
很多人把 gorm.Open() 直接写在 main() 里，看着能跑，上线后一压测就报 too many connections。根本原因是没控制连接池，也没复用单例。
-
InitDB()必须抽到configs/database.go，返回一个全局可复用的*gorm.DB - 一定要调
sqlDB.SetMaxIdleConns(10)和sqlDB.SetMaxOpenConns(100)，否则 MySQL 默认最大连接数 151，很容易打满 -
PrepareStmt: true要开，避免每次查询都编译 SQL，尤其在高频接口中性能差距明显 - 别漏掉
sqlDB.SetConnMaxLifetime(time.Hour)，防止长连接因网络抖动或数据库主动断连导致 panic
ShouldBindJSON 和结构体字段标签不匹配，400 错误查半天
常见现象：前端传 {"name":"xxx","price":99.9}，后端结构体也写了 Name string 和 Price float64，但 c.ShouldBindJSON(&p) 一直报错，err.Error() 却只显示 “invalid character”。
- 检查 JSON tag：字段必须显式加
json:"name"，否则 GIN 默认按 Go 字段名（首字母大写）匹配，而前端传的是小写 key - 绑定失败时，
err是*json.UnmarshalTypeError类型，直接打印不直观；建议用errors.Is(err, json.InvalidUnmarshalError)做判断 - 如果结构体字段带
binding:"required"，但前端没传该字段，ShouldBindJSON就会直接返回 400，不会继续执行后续逻辑 - 慎用
ShouldBind：它会自动根据 Content-Type 选解析器，遇到 multipart/form-data 时可能意外走 JSON 解析，改用ShouldBindWith(&v, binding.JSON)更可控
GORM 查询链式调用中途断掉，Find() 返回空切片却不报错
写 db.Where("status = ?", "active").Preload("User").Find(&orders)，结果 orders 是空 slice，日志里也没报错，查数据库明明有数据。
- 最常见原因：
orders变量没初始化，比如写成var orders []Order是对的，但写成orders := []Order{}或var orders Order就会导致 GORM 无法赋值 -
Preload的关联字段名必须和 struct 中定义的字段名完全一致（大小写敏感），且该字段类型得是对应 model 指针或 slice，比如User *User或Orders []Order - 如果 WHERE 条件字段类型不匹配（比如数据库是
INT，传了 string），GORM 不会报错，但 MySQL 会隐式转换并丢索引——用db.Debug().Where(...).Find(...)看生成的 SQL，再拿去 MySQL 执行EXPLAIN - 软删除字段（
DeletedAt）默认生效，Find()不会查出已软删记录；要查全部得加Unscoped()，但别滥用，容易绕过业务逻辑
路由分组 + 控制器函数传参，别直接传 *gorm.DB
有人在 router.Group("/api").GET("/users", handler.ListUsers) 里，把 db *gorm.DB 作为全局变量传进 handler，结果并发高了以后出现 invalid memory address panic。
- GORM 的
*gorm.DB实例本身是线程安全的，但它的Session、Transaction等上下文不是；直接共享全局 db 实例，在事务或 WithContext 场景下极易混乱 - 正确做法：在 handler 函数内从 context 取 db，或者用依赖注入（如
func ListUsers(c *gin.Context) { db := c.MustGet("db").(*gorm.DB) }），确保每次请求拿到干净上下文 - 更稳妥的方式是封装一个
Handler结构体：type UserHandler struct { DB *gorm.DB }，然后注册路由时用userHandler.ListUsers方法，避免闭包捕获问题 - 别在中间件里做耗时 DB 操作（比如每次请求都查用户权限），应提前缓存或用异步加载，否则 gin 的并发优势会被拖垮
真正卡住人的从来不是语法，而是连接生命周期、绑定字段映射、查询上下文这三个地方——它们不出错则已，一出就是线上静默失败，日志还看不出端倪。
