AutoMigrate仅安全补全表结构：建表、加字段、扩类型、加索引/外键；不删字段、不改名、不降NOT NULL、无版本回滚，生产环境须配合手动迁移。
使用 AutoMigrate 创建表是最直接的方式
Go 项目中用 GORM 创建数据库表，核心就是调用 AutoMigrate 方法。它会根据结构体定义自动建表、加字段、改字段类型（部分数据库支持），但不会删字段或索引。别指望它做全量同步，它只做“安全的向上兼容”。
常见错误是没传指针导致建表失败，比如写 db.AutoMigrate(User{}) 就无效，必须传 &User{}。
- 确保结构体已用
gorm.Model或自定义ID字段，并打上gormtag（如gorm:"primaryKey"） - 连接数据库成功后再调用，否则报
invalid connection - MySQL 默认用
InnoDB，PostgreSQL 需确认用户有CREATE TABLE权限 - SQLite 会自动创建文件，但路径目录必须存在，否则报
no such file or directory
AutoMigrate 不会删除字段或索引，这点必须提前知道
如果你删了结构体里的一个字段，再跑 AutoMigrate，对应数据库列依然存在。GORM 明确不支持反向变更，这是设计选择，不是 bug。想清理字段得手动执行 SQL 或用迁移工具（如 gorp 或 golang-migrate）。
同理，修改字段名（比如把 Name 改成 Fullname）也不会重命名列，而是新增一列 + 留着旧列。GORM 只认结构体字段名和 tag 里的 column，不追踪历史映射。
立即学习“go语言免费学习笔记（深入）”；
- 字段类型变更可能被忽略：比如从
string改成*string，MySQL 里仍是VARCHAR，不会变NULL属性 - 添加
gorm:"uniqueIndex"会建唯一索引，但删掉这个 tag 不会删索引 - 想验证实际执行了什么 SQL？启用 GORM 日志：
db.Debug().AutoMigrate(&User{})
外键和关联字段需要显式配置才能生效
GORM 不会自动为 UserID uint 这类字段加外键约束，哪怕你结构体里写了 gorm:"foreignKey:UserID"。外键依赖数据库引擎支持（MySQL 5.7+ InnoDB、PostgreSQL），且必须主动开启：
- MySQL：初始化时加
gorm.Config{DisableForeignKeyConstraintWhenMigrating: false} - PostgreSQL：默认启用，但需确保引用表已存在（
AutoMigrate顺序很重要） - 关联字段如
Orders []Order不会自动建orders.user_id外键，得在Order结构体里声明UserID uint `gorm:"index"`并配foreignKeytag - SQLite 默认禁用外键，连上后要先执行
PRAGMA foreign_keys = ON
生产环境别只靠 AutoMigrate 做上线部署
开发阶段用 AutoMigrate 很快，但上线时它没法做数据迁移（比如给已有表加 NOT NULL 字段，必须提供默认值）。一旦表里有数据，又没设 default tag，MySQL 会报 invalid default value 错误。
更麻烦的是并发场景：多个实例同时启动并执行 AutoMigrate，可能触发重复建表或锁表失败（尤其 PostgreSQL 的 CREATE TABLE IF NOT EXISTS 在某些版本下不幂等）。
- 上线前建议用
db.Migrator().HasTable(&User{})先判断，避免重复操作 - 涉及数据变更（如加字段+填默认值），务必写独立 SQL 迁移脚本，用
golang-migrate管理 - 结构体加了新字段但不想立刻影响线上读写？先加
gorm:"column:new_field;default:null"，再分批更新
最常被忽略的一点：AutoMigrate 对嵌套结构体、自定义 Scanner/Valuer 类型的支持有限，遇到 JSON 字段或复合主键，最好先查文档确认对应数据库的 behavior。
