automigrate在fiber+gorm中不会自动执行，必须手动触发且易因初始化顺序错误（如未ping就迁移）、传值而非指针（应传&user{}）、字段未导出或外键/索引未显式配置而静默失败；生产环境须改用golang-migrate等版本化工具。
AutoMigrate 在 Fiber + GORM 组合里不会自动执行，必须手动触发且极易因初始化顺序或指针传参错误而静默失败。
为什么 db.AutoMigrate(&User{}) 在 Fiber 启动时没建表
常见现象是服务跑起来了、路由也通了，但查数据库发现 User 表根本不存在，日志也没报错。这不是 Fiber 拦截了迁移，而是你调用 AutoMigrate 的时机或方式错了：
- 在
db还没完成连接（比如gorm.Open后没db.Ping()）就调AutoMigrate，GORM 会静默跳过甚至 panic - 传了
User{}而不是&User{}——AutoMigrate必须接收结构体指针才能读取struct tag，否则直接忽略该模型 - Fiber 的
app.Get等路由注册逻辑常被误当成“初始化入口”，实际应放在main()函数靠前位置，在app.Listen()之前完成 DB 初始化和迁移 - 字段名首字母小写（如
name string）导致 Go 不导出，GORM 完全看不见这个字段，自然不会建对应列
外键和索引在 Fiber 项目里为何总是不生效
不是 Fiber 干扰了 GORM，而是 GORM 默认禁用外键、也不自动生成索引——这跟框架无关，是 GORM 的保守设计。你在 Fiber 的 main.go 里配了 gorm.Config，但漏掉了关键开关：
- 外键必须显式开启：
DisableForeignKeyConstraintWhenMigrating: false，否则哪怕写了User User `gorm:"foreignKey:UserID"`，约束也不会进数据库 - 外键字段本身也要打标：仅
UserID uint不够，得写成UserID uint `gorm:"not null"`或配合关联字段完整声明 - 唯一索引不能只靠业务逻辑保证，要写
Email string `gorm:"uniqueIndex"`；复合索引需共用同一 index 名，例如Name string `gorm:"index:idx_user_name_age"`和Age int `gorm:"index:idx_user_name_age"` - 多对多中间表（如
UserRole）GORM 绝对不自动生成，必须自己定义 struct 并单独加入AutoMigrate调用列表
如何在 Fiber 项目中安全触发 AutoMigrate
别把迁移塞进 HTTP handler，也别依赖 “启动即迁移” 的幻觉。推荐在 main() 函数里分三步硬控制：
- 先用
gorm.Open创建*gorm.DB，再立刻调db.Ping()确认连接就绪 - 紧接着调
db.AutoMigrate(&User{}, &Product{}, &UserRole{})，**一次性传所有模型指针**，比循环调用更可靠，GORM 也能理清外键依赖顺序 - 加一层验证：迁移后立即用
db.Migrator().HasTable(&User{})和db.Migrator().HasColumn(&User{}, "email")检查关键结构是否真到位，避免静默跳过 - 如果要用表选项（如 MySQL 引擎），得提前
db.Set("gorm:table_options", "ENGINE=InnoDB DEFAULT CHARSET=utf8mb4")，再执行AutoMigrate
生产环境千万别只靠 AutoMigrate 做迭代
它不记录版本、不支持回滚、无法控制 DDL 执行顺序，字段类型变更（如 int → int64）默认不触发 ALTER COLUMN，除非你显式写 gorm:"type:bigint"。更危险的是：SQLite 或 MySQL 5.7 以前遇到改长度或重命名列，GORM 会重建表——无事务、大表易卡死、数据可能丢失。
真正上线前，必须用 golang-migrate CLI 驱动 SQL 迁移，把每次变更固化为带序号的 .up.sql 文件；AutoMigrate 只适合本地开发快速对齐结构，或 CI 流水线里做 schema 验证。最易被忽略的一点：迁移完成后，没人检查 schema_migrations 表是否存在、内容是否匹配当前代码模型——这恰恰是线上环境 schema 脱节的起点。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
