gorm automigrate 不建表且不报错，因其仅比对结构差异，不校验连接、权限、类型兼容性等；需确保已成功初始化 *gorm.db、struct tag 正确、mysql 严格模式下类型精确匹配，并用 db.migrator().currentdatabase() 验证连接。
为什么 GORM 的 AutoMigrate 有时不建表也不报错
因为 AutoMigrate 只检查结构差异，不校验数据库连接有效性，也不处理权限不足、表名冲突或字段类型不兼容等隐性失败。常见现象是执行后无输出、无错误、但表没建出来。
- 确保调用前已成功
gorm.Open并拿到非 nil 的*gorm.DB实例，否则AutoMigrate在空指针上静默失败 - 检查 struct tag：必须有
gorm:"primaryKey"或字段名匹配数据库主键约定（如ID），否则 GORM 可能跳过该模型 - MySQL 8+ 默认 strict mode 下，若字段类型映射不精确（比如 Go 的
int映射成TINYINT但已有同名表含INT），AutoMigrate会跳过变更且不提示 - 建议加一句
db.Migrator().CurrentDatabase() != ""做连接兜底验证
First 和 Take 在查询单条记录时到底选哪个
语义不同：First 按主键升序找第一条，Take 不排序直接取结果集首条；实际行为差异在有没有 ORDER BY。
- 用
First当你依赖“最小 ID”逻辑（例如查最早创建的用户），它隐式加ORDER BY id ASC - 用
Take当你只关心“随便一条”，比如做存在性检查或采样，避免多余排序开销 - 两者都返回
ErrRecordNotFound，但First在有WHERE条件时仍会排序，Take完全不加ORDER BY - 示例：
db.Where("status = ?", "active").First(&u)等价于SELECT * FROM users WHERE status = 'active' ORDER BY id LIMIT 1
事务里嵌套调用函数，为什么 Rollback 不生效
因为 GORM 的事务对象不自动透传——你在函数内用的 db 如果不是从外部事务传入的，就还是全局或新连接实例，和事务无关。
- 所有事务内操作必须复用同一个
*gorm.DB实例，不能在函数里重新gorm.Open或用包级变量DB - 推荐把
*gorm.DB作为参数显式传入业务函数，而不是依赖闭包或全局状态 - 注意
db.Session(&gorm.Session{PrepareStmt: true})这类操作会生成新实例，需确保 session 也基于事务 db 创建 - 调试技巧：打印
db.Statement.ConnPool == nil，为 false 才说明处于有效事务中
MySQL 时间字段存 time.Time 为什么查出来总是零值
本质是 scan 阶段类型不匹配：GORM 默认把 MySQL 的 DATETIME 映射为 time.Time，但若 struct 字段声明为 *time.Time 或未初始化，且数据库值为 NULL，就会跳过赋值导致零值残留。
- 确认字段是否允许 NULL：对应 Go 字段用
*time.Time，否则 MySQL 的 NULL 无法被安全接收 - 检查 timezone：MySQL 连接字符串必须带
parseTime=true&loc=Local，否则time.Time解析失败，默认为零时间 - 避免用
sql.NullTime—— GORM 对它的支持不稳定，优先用*time.Time - 示例 DSN：
user:pass@tcp(127.0.0.1:3306)/db?parseTime=true&loc=Local
事情说清了就结束
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
