AutoMigrate不建表或不加字段，因其仅执行最小必要变更：不删字段、不改类型、不重命名列、不自动处理外键；需显式传指针、配gorm标签（如primaryKey、type、default）、启用外键开关，并用HasTable/HasColumn预检。
为什么 AutoMigrate 有时不创建表或不加字段
因为 AutoMigrate 只做“最小必要变更”：它不会删除字段、不会修改字段类型、不会重命名列，也不会自动处理外键约束变更。比如你删了结构体字段，表里对应列还在；改了 string 字段长度从 type:varchar(255) 到 type:varchar(50)，GORM 默认不执行 ALTER COLUMN（尤其在 MySQL 中可能静默忽略）。
实操建议：
- 开发初期可依赖
AutoMigrate快速建模，但上线前必须导出 SQL 并人工核对 - 字段类型变更务必显式加
type标签，并确认数据库驱动是否支持该类型推导（例如 PostgreSQL 的jsonb需写gorm:"type:jsonb"） - 新增非空字段（
NOT NULL）时，必须提供默认值，否则迁移会失败——用default标签或数据库级DEFAULT值 - 想让 GORM 尝试同步索引，得在 struct tag 里明确写
index或uniqueIndex，否则AutoMigrate不管索引
如何安全地做字段重命名或类型调整
GORM 的 AutoMigrate 不支持重命名字段，也不安全地变更类型。真要改，得手动写迁移逻辑。
实操建议：
- 用
db.Migrator().RenameColumn手动重命名，例如：db.Migrator().RenameColumn(&User{}, "name", "full_name") - 类型变更分两步：先加新字段 → 迁移数据 → 删旧字段，避免停机。不要依赖
AutoMigrate自动“升级”int到int64 - PostgreSQL 用户注意：
RenameColumn在 v1.23+ 才真正生效，老版本需直接执行db.Exec("ALTER TABLE ... RENAME COLUMN ...") - MySQL 用户慎用
ModifyColumn：GORM 不校验兼容性，把VARCHAR(10)改成TEXT可能成功，但反过来会报错
模型定义中哪些 struct tag 最容易被忽略却影响迁移结果
光写字段名和类型远远不够。GORM 依赖 struct tag 控制建表细节，漏掉关键 tag 会导致字段行为与预期不符。
实操建议：
-
gorm:"primaryKey"—— 不写的话，GORM 默认找叫ID的字段当主键；如果主键叫user_id却没标，迁移会建错主键甚至报错 -
gorm:"column:xxx"—— 当数据库列名和 Go 字段名不一致时必须显式声明，否则AutoMigrate会按字段名建列，导致查询失败 -
gorm:"default:0"或gorm:"default:CURRENT_TIMESTAMP"—— 控制数据库默认值，不是 Go 层面的零值；没写时，MySQL 可能设为NULL，PG 可能拒绝插入 -
gorm:"not null"和gorm:"null"要配对看：前者强制非空，后者允许为空（且不加default时，PG 会建为NULL，MySQL 可能隐式加DEFAULT NULL）
用 db.Migrator().HasTable 和 HasColumn 做迁移前检查
硬调 AutoMigrate 有风险，尤其在多实例部署时可能并发执行。更稳妥的方式是先判断再操作。
实操建议：
- 启动时检查表是否存在：
if !db.Migrator().HasTable(&User{}) { db.Migrator().CreateTable(&User{}) } - 只对缺失字段执行添加：
if !db.Migrator().HasColumn(&User{}, "status") { db.Migrator().AddColumn(&User{}, "status") } -
AddColumn不会覆盖已有字段，但要注意：它不处理默认值，得配合ModifyColumn或后续Exec补默认值 - 这些方法返回
error，别忽略。例如 PostgreSQL 中权限不足时HasTable会返回"permission denied"而不是false
AutoMigrate 调用背后都有数据库方言和驱动实现的细节差异。最常出问题的地方，往往是你以为它“应该懂”的那部分——比如时间字段要不要带时区、JSON 字段用不用指定类型、外键约束是否启用。上线前连上真实库跑一次 AutoMigrate 并 SHOW CREATE TABLE 对比，比读十遍文档都管用。 
