Iris框架本身不提供内置数据库迁移功能，它专注HTTP路由与响应处理，不捆绑ORM或迁移工具；所谓“Iris数据库迁移”实为项目集成GORM等第三方ORM后使用的迁移能力。
Iris 框架本身不提供内置的数据库迁移功能。它是一个轻量、高性能的 Go Web 框架，专注 HTTP 路由、中间件和响应处理，不捆绑 ORM 或迁移工具。你看到的 “Iris 数据库迁移” 相关内容，基本都源于混淆：把用 Iris 搭建的项目 + 外部 ORM（如 GORM）的迁移操作，误认为是 Iris 自带的能力。
要实现迁移，你必须显式引入并集成第三方迁移方案。下面说清楚怎么做、为什么选、以及最容易翻车的地方。
用 GORM + gormigrate 做迁移（最常见组合）
Iris 项目中普遍搭配 GORM 操作数据库，而 GORM 本身不带迁移执行器，需靠 gormigrate 或手写迁移逻辑。
- gormigrate 是轻量封装，帮你按顺序执行 up()/down() 函数，不生成 SQL，也不解析模型变更
- 它不自动发现结构差异，所有迁移逻辑必须手动编写 —— 这反而是可控性和可审查性的保障
- 示例流程：
安装：go get github.com/go-gorm/gorm 和 go get github.com/nikolaydubina/gormigrate
定义迁移：
g := gormigrate.New(db, gormigrate.DefaultConfig, []*gormigrate.Migration{
{
ID: "20240101000000_add_users_table",
Migrate: func(tx *gorm.DB) error {
return tx.AutoMigrate(&User{})
},
Rollback: func(tx *gorm.DB) error {
return tx.Migrator().DropTable(&User{})
},
},
})在 main.go 启动时调用 g.Migrate() 即可
AutoMigrate 不是迁移替代品 —— 它会静默修改字段、丢失数据；真正生产迁移必须用显式 CreateTable/AddColumn 等语句
为什么不用 Flyway / Liquibase？
虽然Flyway 和 Liquibase 是 Java 生态主流迁移工具，Go 生态中也有 golang-migrate（推荐），但它们和 Iris 的集成有隐性成本：
- 需要额外维护 SQL 文件路径、版本命名规则、CLI 执行时机
- Iris 应用启动时若依赖迁移完成，就得在 main() 中调用 CLI 子进程或嵌入 migrate 库，增加启动复杂度
- golang-migrate 的 Go API 虽可用，但错误处理松散，比如迁移失败时可能只返回 nil 错误却跳过后续步骤
- 如果团队已用 GORM 模型定义业务逻辑，再切回纯 SQL 迁移，会带来双维护负担（模型改了，SQL 迁移也得同步）
迁移文件该放哪？怎么触发？
Iris 项目没有约定迁移目录位置，但实际部署中必须解决两个问题：
- 迁移代码必须与应用二进制绑定（不能靠外部 CLI 临时执行），否则容器重启或蓝绿发布时易漏执行
- 推荐做法：把迁移注册逻辑放在 internal/migration/ 下，导出一个 Migrate(*gorm.DB) error 函数，在 app.Run() 前调用
- 切忌把迁移逻辑塞进 HTTP handler —— 这会导致每次请求都尝试执行，或被并发触发多次
- 更危险的是：在 GET /health 里偷偷跑迁移 —— 一旦健康检查高频调用，可能重复建表、锁表甚至阻塞主库
关键点就一个：迁移不是“上线后随便跑跑”的操作，它是应用启动生命周期的一部分，必须原子、幂等、可观测。你写的每一条 AddColumn 都该有对应测试，且在 staging 环境走一遍全链路 —— 因为 Iris 不拦你，但 MySQL 会用 ERROR 1832 (HY000): Cannot change column 'xxx': used in a foreign key constraint 给你上课。
