AutoMigrate没建表主因是传参或标签错误：必须传结构体指针&User{}，ID字段需显式加gorm:"primaryKey"，外键字段要配对声明且初始化时关闭DisableForeignKeyConstraintWhenMigrating。
AutoMigrate 为什么没建表？传参和标签必须对齐
最常见的情况是 db.AutoMigrate(&User{}) 执行后数据库里啥也没出现，连表都没建。这不是 GORM 失效，而是它根本没“看懂”你的结构体。
关键点有三个：
- 必须传结构体指针：
&User{}，传User{}或new(User)都不行 —— GORM 依赖反射读取 struct tag，非指针无法获取字段标签 -
ID字段不等于主键：即使叫ID uint，GORM 也不会自动认作主键，得显式加gorm:"primaryKey" - 外键字段（如
CompanyID uint）要配关联字段，否则不会生成外键约束：Company Company `gorm:"foreignKey:CompanyID"`
另外，MySQL 默认禁用外键迁移，初始化 DB 时得关掉开关：DisableForeignKeyConstraintWhenMigrating: false，否则所有 foreignKey 标签都无效。
字段改了但数据库没变？类型变更不是全自动的
AutoMigrate 不会盲目执行 ALTER COLUMN，它只在驱动支持 + 标签明确的前提下才改类型。比如：
立即学习“go语言免费学习笔记（深入）”；
-
Age int→Age int64：默认不做任何事，必须加gorm:"type:bigint"显式声明 -
Age int→Age *int（允许 NULL）：GORM 会尝试把列从 NOT NULL 改为可空，但 MySQL 5.7+ 才稳定支持；旧版可能静默失败 -
Content string→Content string `gorm:"size:2000"`：MySQL/PostgreSQL 会扩长度，SQLite 不支持 ALTER COLUMN，会重建整张表（大表危险）
别指望它猜你意图。改类型、调精度、扩长度，都得靠标签说话。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
生产环境跑 AutoMigrate 前必须验证的三件事
它永远静默跳过“无需操作”的情况 —— 表已存在、字段已就位、外键开关关着……它都不会报错，更不会告诉你“什么都没干”。上线前务必主动确认：
- 用
db.Migrator().HasTable(&User{})检查表是否存在 - 用
db.Migrator().HasColumn(&User{}, "email")确认关键字段已落地 - 用
db.Migrator().HasIndex(&User{}, "idx_users_email")验证索引是否生效（尤其唯一索引）
别信日志里那句 “AutoMigrate success”，它只表示函数没 panic，不代表结构真的同步了。
多模型迁移顺序和中间表怎么处理？别指望 GORM 自动推导
批量迁移推荐写成 db.AutoMigrate(&User{}, &Order{}, &UserRole{})，而不是循环三次单独调。GORM 内部会按外键依赖排序，避免 “表不存在” 报错。
但有一个硬限制：多对多中间表（如 UserRole）GORM 绝对不自动生成。哪怕你写了 Users []User `gorm:"many2many:user_roles;"`，它也只管两边的外键字段，中间表结构必须自己定义并显式迁移：
type UserRole struct {
UserID uint `gorm:"primaryKey"`
RoleID uint `gorm:"primaryKey"`
}
// 必须单独加这一行
db.AutoMigrate(&UserRole{})
漏掉这一步，插入关联数据时会直接报 “table user_roles doesn’t exist”。
