AutoMigrate 未建表或报错“relation does not exist”的根本原因是其仅作用于当前可识别的 struct，不递归处理嵌套、不自动创建外键约束（需显式启用），且不删字段或改类型；常见问题包括传参错误、字段未导出、DB未就绪、schema不匹配及类型变更不生效。
AutoMigrate 为什么没建表或报错 ERROR: relation "xxx" does not exist
根本原因不是 GORM 不会建表，而是 AutoMigrate 只作用于它「当前能识别到的 struct」，且默认不递归处理嵌套、不自动创建外键约束（除非显式启用），更不会删字段或改类型。
常见踩坑点：
-
AutoMigrate必须传入具体 struct 类型（如db.AutoMigrate(&User{})），不能只传指针变量名（db.AutoMigrate(user)错） - struct 字段没加
gormtag 或首字母小写（Go 导出限制），GORM 就直接忽略该字段，表里自然没有 - 数据库连接未就绪（比如
db是 nil 或Open后没调Ping），AutoMigrate会静默失败或 panic - PostgreSQL 下若 schema 非
public（如用search_path切到my_schema），需在 DSN 加search_path=my_schema，否则表建在public而查询去别处找
MySQL/PostgreSQL 下字段类型不一致，AutoMigrate 为何不自动更新
GORM 的 AutoMigrate 默认是「安全同步」：只建缺失表/列，不删列、不改类型、不删索引。这是设计使然，不是 bug。
比如你把 Name string `gorm:"size:50"` 改成 size:100，MySQL 下它通常不生效（PostgreSQL 更严格，直接跳过）；把 Age int 改成 Age uint，也不会触发 ALTER COLUMN。
立即学习“go语言免费学习笔记（深入）”；
真要改结构，得手动执行 SQL 或用迁移工具（如 migrate CLI + golang-migrate）。GORM 官方明确不支持「反向工程+差异应用」式的智能变更。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
临时绕过办法（仅开发环境）：
- 加
gorm:"columnType:varchar(100)"强制指定底层类型（但跨库不兼容） - 删掉表再跑
AutoMigrate（⚠️生产禁用） - 用
db.Migrator().DropColumn(&User{}, "name")手动删列，再重新 migrate（仍需自己写逻辑判断）
如何让 AutoMigrate 支持外键和关联表自动创建
默认情况下，AutoMigrate 对 has many、belongs to 这类关系「只建主表字段，不建外键约束，也不建 join 表」。
必须显式开启约束支持，并确保 struct tag 写法正确：
- 启用外键：初始化 DB 时加
gorm.Config{DisableForeignKeyConstraintWhenMigrating: false} -
UserID uint字段要配gorm:"foreignKey:UserID"，否则 GORM 不知道哪是外键 - 多对多需要独立 struct 表示 join 表（如
UserRoles），并单独AutoMigrate它；GORM 不会自动生成中间表 - PostgreSQL 注意：若用
SET CONSTRAINTS ALL DEFERRED类逻辑，外键约束名不能重复，建议用gorm:"constraint:OnUpdate:CASCADE,OnDelete:CASCADE;"显式控制
生产环境能否直接用 AutoMigrate？
不能。它没有版本控制、无法回滚、不记录变更历史、并发执行可能冲突——这些是上线前必须卡住的红线。
真实项目中，AutoMigrate 只适合三类场景：
- 本地开发快速拉起 demo 环境
- CI 流水线中每次构建新测试库（配合
Dockerized DB） - 内部工具类服务，数据可丢、结构极简单（如配置缓存表）
只要表里有真实业务数据，就必须切到基于版本号的迁移方案：用 github.com/golang-migrate/migrate/v4 管理 .sql 文件，GORM 只负责运行时 ORM 映射。这点很容易被忽略，等线上 ALTER TABLE 锁表两小时才反应过来就晚了。
