gorm.Open panic 的根本原因是未传入已初始化的 sql.DB 实例，因 GORM v2 不再自动注册驱动；正确做法是先 sql.Open 获取 sql.DB 再传给 gorm.Open。
gorm.Open 为什么总是 panic: failed to initialize database
多数人在第一次调用 gorm.Open 时遇到 panic，根本原因不是 DSN 写错，而是忘了传入一个已初始化的数据库驱动实例。GORM v2 不再自动注册驱动，sql.Open 返回的 *sql.DB 必须显式传给 gorm.Open。
- 正确做法：先用
sql.Open("mysql", dsn)或sql.Open("postgres", dsn)获取*sql.DB，再传给gorm.Open(gormdb, &gorm.Config{}) - 常见错误：直接
gorm.Open("mysql", dsn)—— 这是 v1 写法，v2 已移除，会 panic 并提示 “unsupported driver” - PostgreSQL 用户注意：
pgx驱动需额外导入github.com/jackc/pgx/v5/pgxpool并用pgxpool.New初始化，不能只靠database/sql+pgx的默认注册
AutoMigrate 执行后表没建出来或字段缺失
AutoMigrate 不是“同步 schema”，它只做增量变更：新增字段、新增索引、新增表，但不会删除字段、不会修改字段类型、也不会重命名字段。一旦结构定型，别依赖它回滚或重构。
- 字段消失？检查 struct tag：GORM 默认忽略首字母小写的字段，必须加
gorm:"column:name"显式声明，否则不映射 - 类型不一致？比如 struct 中是
int64，但 DB 里是BIGINT UNSIGNED，AutoMigrate不会改，甚至可能静默跳过该字段 - 外键失效？MySQL 8.0+ 默认开启严格模式，如果关联字段没加
gorm:"foreignKey:UserID"且类型不匹配（如uintvsint），迁移会失败但不报错，得开logger.Default.LogMode(logger.Info)看 SQL 日志
Where 条件里用 map 或 struct 传参，为什么查不到数据
GORM 对 Where 的 map / struct 解析是浅层反射，不做嵌套展开，也不处理零值过滤逻辑。它把 key 当字段名、value 当参数值，但 value 是零值（0、""、nil）时，仍会生成 = ? 条件，而不是跳过。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 例如
Where(map[string]interface{}{"name": "", "age": 0})会生成WHERE name = '' AND age = 0，而非你期望的“忽略空值” - 安全写法：用链式
Where("name != ?", "").Where("age > ?", 0)，或封装一个条件构建函数，手动跳过零值 - struct 传参更危险：字段名必须和 DB 列名完全一致（区分大小写），且所有非零字段都会参与 WHERE；
gorm:"column:user_name"不影响Where(&User{Name: "a"})的解析逻辑
事务里嵌套 Save 和 Create，为什么部分数据没提交
GORM 的 Save 和 Create 在事务内默认使用传入的 *gorm.DB 实例，但如果你在事务中又调用了未带事务上下文的全局 db 变量，那操作就跑出事务了——这是最隐蔽的数据不一致来源。
立即学习“go语言免费学习笔记（深入）”；
- 务必确认：所有 DB 操作都基于同一个
*gorm.DB实例，该实例来自tx := db.Begin()后的tx.Create(...)，而不是原始db.Create(...) -
Save会尝试 UPDATE，若记录不存在则 INSERT；但在事务中，如果主键冲突或唯一约束触发，它不会报错，而是静默失败（除非你检查result.Error） - 关联创建（
Preload或Association）在事务中不自动继承事务上下文，必须显式用tx.Session(&gorm.Session{NewDB: true})包裹，否则关联数据写进主库，不在事务里
真正麻烦的是跨函数调用时隐式用了不同 DB 实例，这种 bug 很难复现，日志里也看不出异常，只能靠单元测试覆盖事务路径并断言最终状态。
