AutoMigrate不建表也不报错，因其仅比对结构差异，不校验连接有效性、权限或类型兼容性；需确保*gorm.DB非nil、struct含primaryKey标签、MySQL严格模式下类型精确匹配，并用db.Migrator().CurrentDatabase()验证连接。
DB.AutoMigrate 不是“建表万能钥匙”，它只做增量同步，且默认不报错——这是 Gin + GORM 集成中最容易被当成功能、实则埋雷的第一步。
为什么 AutoMigrate 执行了却没建表？
常见现象：db.AutoMigrate(&User{}) 返回 nil 错误，但 MySQL 中查不到 users 表。
原因在于：AutoMigrate 默认跳过已存在但结构不一致的表，也不校验 DSN 权限或数据库是否存在。它只尝试“让表结构趋近模型定义”，不是 DDL 执行器。
- 确保
dsn指向的数据库（如task_manager）已手动创建，GORM 不会自动建库 - 检查 MySQL 用户是否拥有
CREATE和ALTER权限（仅SELECT权限会导致静默失败） - 若表已存在但字段少，
AutoMigrate会补字段；但若类型冲突（如string映射到INT），它可能跳过而非报错 - 加
logger查看真实 SQL：&gorm.Config{Logger: logger.Default.LogMode(logger.Info)}
Create 成功但数据库没数据？检查 RowsAffected
现象：调用 db.Create(&u) 后 err == nil，但 SELECT * FROM users 查不到记录。
根本原因：GORM 的 Create 只捕获 SQL 层错误（如连接中断），不校验业务逻辑合法性。
-
uint8字段传入 300 → 溢出归零 → 主键为 0 → 被当成新记录插入，但 MySQL 自增主键不接受 0 → 实际执行的是INSERT ... ON DUPLICATE KEY UPDATE静默跳过 - 结构体含非零
ID字段 →Create自动转为UPDATE，语义完全偏离 - 必须显式检查：
if result.RowsAffected == 0 { /* 处理无写入 */ } - 关键字段建议加
validator校验：Name string `binding:"required,min=2"`
CreatedAt/UpdatedAt 时间错乱或被 JSON 覆盖
现象：API 接收 {"created_at": "2024-01-01"}，入库后时间变成 0001-01-01 或被覆盖为接收时间。
问题根源：GORM 的时间字段默认信任 JSON 解析结果，不区分“用户输入”和“系统生成”。
- 去掉结构体字段的
jsontag，或设为json:"-"（禁止 JSON 绑定） - 用
gormtag 显式控制：CreatedAt time.Time `gorm:"autoCreateTime"`、UpdatedAt time.Time `gorm:"autoUpdateTime"` - 避免在
ShouldBindJSON时直接绑定 model，改用专用 input struct（如CreateUserInput），再手动赋值到 model - MySQL 层的
DEFAULT CURRENT_TIMESTAMP对 GORM 无效——它不读取该元信息
软删除导致前端“删不干净”
现象：调用 db.Delete(&u) 后，再次 db.Find 还能查到该记录。
这不是 bug，是 GORM 默认启用软删除（DeletedAt 非空即隐藏）。
-
Delete实际执行的是UPDATE SET deleted_at = NOW()，不是DROP - 查询时需显式启用软删除：
db.Unscoped().Where("id = ?", id).Delete(&User{}) - 前端响应应明确返回
deleted_at字段，避免缓存旧数据；响应头加Cache-Control: no-cache - 若不需要软删除，在模型中禁用：
type User struct { gorm.Model DeletedAt gorm.DeletedAt `gorm:"index;not null"` }→ 改为DeletedAt gorm.DeletedAt `gorm:"-"`
Gin + GORM 的集成难点从来不在“连得上”，而在于每个默认行为都假设你理解它的隐式契约——比如 AutoMigrate 不建库、Create 不校验值、Delete 不真删。漏掉任意一个，都会变成线上静默故障。
