automigrate不建表也不报错，因其仅比对结构差异，不校验连接有效性、权限或类型兼容性；需确保*gorm.db非nil、struct含primarykey标签、mysql严格模式下类型精确匹配，并用db.migrator().currentdatabase()验证连接。
GORM 是当前 Go 生产项目中最常落地的 ORM 方案，不是因为它最轻或最快，而是它在结构体映射、迁移控制、事务显式性上踩中了真实开发的痛点。
AutoMigrate 为什么没建表也不报错
常见现象是调了 db.AutoMigrate(&User{})，日志没输出、返回 nil error，但数据库里就是没表。这不是 bug，是设计使然：它只比对已有表结构和模型定义的差异，不校验连接是否有效、权限是否足够、字段类型是否兼容。
- 先确认
db是非 nil 的 *gorm.DB 实例——如果gorm.Open失败但你忽略了 err，后续所有操作（包括 AutoMigrate）都在空指针上静默失败 - 检查 struct tag：
ID字段必须带gorm:"primaryKey"，否则 GORM 可能跳过整个模型；CreatedAt等时间字段要配gorm:"autoCreateTime"才会生成对应列 - MySQL 8+ 默认 strict mode 下，若已有同名表但字段类型不匹配（比如模型用
int64，原表是INT），AutoMigrate 会跳过变更且不提示 - 加一句
db.Migrator().CurrentDatabase()验证连接是否就绪，返回非空字符串才算真正连上了
First 和 Take 查询单条记录的区别在哪
两者都用于取一条记录，但语义和 SQL 行为完全不同，选错会影响结果正确性和性能。
-
First总是隐式加ORDER BY id ASC，哪怕你没写条件；它找的是“主键最小的那条”，适合查最早创建的用户、首条配置等依赖顺序的场景 -
Take完全不加ORDER BY，直接取查询结果集的第一行；适合存在性检查（db.Where("name = ?", "admin").Take(&u)）、采样、或你明确知道 WHERE 条件只会命中一条且不关心顺序 - 有 WHERE 条件时，
First仍会排序，Take不会——这对大表可能差出一个索引扫描级别 - 两者都返回
gorm.ErrRecordNotFound，但不能靠错误类型反推行为是否符合预期
事务里嵌套函数调用，Rollback 为啥不生效
根本原因是 GORM 的事务对象不自动透传。你在外部开启事务得到一个 *gorm.DB，但如果嵌套函数里用的是包级变量 DB 或重新 gorm.Open，那就完全脱离了事务上下文。
- 所有事务内操作必须复用同一个
*gorm.DB实例，不能依赖闭包捕获或全局 DB 变量 - 推荐把
*gorm.DB显式作为参数传入业务函数，例如func CreateUser(tx *gorm.DB, u *User) error - 注意
db.Session(&gorm.Session{PrepareStmt: true})这类调用会返回新实例，必须确保它是基于事务 db 创建的，而不是全局 db - 调试时打印
db.Statement.ConnPool == nil，为false才说明当前 db 真正在事务中
MySQL DATETIME 查出来是零值，怎么破
本质是 scan 阶段类型不匹配：GORM 默认把 MySQL 的 DATETIME 映射为 time.Time，但如果你的 struct 字段声明为 *time.Time 且未初始化，或者数据库该字段为 NULL 但 Go 字段不是指针，scan 就会失败并保持零值。
- 字段类型必须严格对应：数据库允许 NULL → Go 字段用
*time.Time；不允许 NULL → 用time.Time，且确保 DSN 含parseTime=True - DNS 必须带
parseTime=True&loc=Local，否则 time.Time 解析失败，默认回零值 - 别用
sql.NullTime，GORM 对它的支持不稳定；坚持用*time.Time+ 非空校验更可控 - 如果表里已有脏数据（比如 DATETIME 列存了
0000-00-00 00:00:00），MySQL 8+ 默认拒绝解析，需改表或关 strict mode
最易被忽略的点是：AutoMigrate 不验证字段类型兼容性，First/Take 的排序隐含性，事务实例传递的“隐形断层”，以及 time.Time 的零值陷阱——它们都不报错，但让逻辑在某个边界安静崩塌。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
