gorm.Open panic 主因是未检查返回的 error 导致操作 nil *gorm.DB；正确做法是先检查 err，再用 db.DB().Ping() 验证连接，并确保 DSN 含 parseTime=true&loc=Local。
gorm.Open 连接数据库时为什么总 panic？
多数人第一次用 GORM 就卡在这儿：没处理 gorm.Open 返回的 error，直接对 nil *gorm.DB 调用方法，触发 panic。
正确做法是显式检查 error，并用 sql.Open 预检连接（GORM 不自动做底层连通性验证）：
db, err := gorm.Open(mysql.Open(dsn), &gorm.Config{})
if err != nil {
log.Fatal("failed to connect database:", err)
}
// 建议加一层健康检查
sqlDB, err := db.DB()
if err != nil {
log.Fatal("failed to get *sql.DB:", err)
}
if err = sqlDB.Ping(); err != nil {
log.Fatal("database ping failed:", err)
}
-
gorm.Open只初始化 GORM 层，不验证 DB 是否可达 - 必须调用
db.DB()拿到*sql.DB后再Ping() - MySQL DSN 中别漏掉
parseTime=true&loc=Local，否则time.Time字段可能解析失败
struct tag 里 gorm:"primaryKey" 和 gorm:"column:xxx" 怎么配合用？
GORM 默认按 struct 字段名映射列名，大小写敏感且会自动转 snake_case。但实际表结构常不遵循这套规则，必须靠 tag 控制。
常见组合逻辑：
立即学习“go语言免费学习笔记（深入）”；
type User struct {
ID uint `gorm:"primaryKey"`
Name string `gorm:"column:user_name"`
CreatedAt time.Time `gorm:"column:created_dt"`
}
-
primaryKey必须显式声明，GORM 不再默认识别ID或Id -
column优先级高于字段名，但不会影响关联字段（如UserID关联外键仍需额外用foreignKeytag） - 避免混用
column和name（后者已废弃），也别在同一个字段上重复定义冲突规则
Preload 关联查询为什么查不到数据？
Preload 看似简单，但漏掉几个关键点就会返回空 slice 或 panic：
JTBC网站内容管理系统5.0.3.1
下载
JTBC CMS(5.0) 是一款基于PHP和MySQL的内容管理系统原生全栈开发框架，开源协议为AGPLv3，没有任何附加条款。系统可以通过命令行一键安装，源码方面不基于任何第三方框架，不使用任何脚手架，仅依赖一些常见的第三方类库如图表组件等，您只需要了解最基本的前端知识就能很敏捷的进行二次开发，同时我们对于常见的前端功能做了Web Component方式的封装，即便是您仅了解HTML/CSS也
- 主表记录本身必须存在，
Preload不会“拉起”主表——先查不到 User，就不可能加载其 Orders - 关联字段名必须和 struct 中定义的字段名完全一致（不是数据库列名），例如
Orders字段名要和has many关系声明匹配 - 若用
Joins+Select，Preload会被忽略——二者互斥，不能混用 - 嵌套 Preload 如
Preload("Orders.Items")要求中间 struct（Orders）也有正确的gorm.Model定义和外键 tag
调试建议：打开 GORM 日志，确认生成的 SQL 是否含预期的 JOIN 或子查询：
db = db.Debug() // 开启后每条操作都会打印 SQL
事务里用 Save 还是 Create？
在事务中误用 Create 是高频 bug 来源：Create 会忽略 struct 中已存在的主键值，强制 INSERT；而 Save 会根据主键是否存在决定 INSERT 或 UPDATE。
- 想确保插入新记录 → 用
Create，但需提前清空主键字段（如u.ID = 0） - 想“有则更新、无则插入” → 用
Save，但注意它不触发BeforeCreate钩子，只走BeforeSave - 批量操作慎用
CreateInBatches，它内部会拆成多个事务，无法与外层事务联动
更安全的做法是显式控制：先 FirstOrInit 判断存在性，再 Save 或 Updates。
复杂业务里，GORM 的钩子执行顺序、预加载缓存、事务隔离级别这些细节，比语法本身更容易出问题。别依赖“自动推断”，每个关联、每次保存，都该有明确的意图和验证。
