1. GORM 迁移概述
什么是数据库迁移
数据库迁移（Database Migration）是指对数据库结构进行版本化、可追溯的变更管理过程。在应用开发中，数据模型会随着业务需求不断演进——新增字段、修改类型、添加索引、创建关联表等。迁移的核心目标就是让这些结构变更能够安全、可重复、可回滚地在不同环境（开发、测试、生产）中执行。
关键认知： 迁移 ≠ 数据备份。迁移只管理表结构、索引、约束等元数据，不负责数据内容。数据迁移（如 ETL）是另一回事。
传统迁移工具（如 Flyway、Liquibase）使用 SQL 脚本管理版本；而 GORM 的 AutoMigrate 则通过 Go 结构体自动同步表结构，属于声明式迁移的一种实现。
| 对比维度 | 传统 SQL 迁移 | GORM AutoMigrate |
|---|---|---|
| 变更载体 | SQL 脚本（.sql 文件） | Go 结构体标签 + 字段定义 |
| 版本控制 | 手动维护版本号/时间戳 | 自动检测差异，无需显式版本 |
| 回滚能力 | 提供回滚脚本 | 不支持自动回滚 |
| 适用场景 | 生产环境、多人协作、复杂变更 | 开发/测试环境、快速原型 |
GORM AutoMigrate 简介
GORM 的 AutoMigrate 是 *gorm.DB 实例上的一个方法，它会自动检查数据库中是否已存在与 Go 结构体对应的表，如果不存在则创建；如果存在但字段有差异，则尝试增量修改（添加新列、修改列类型、添加索引等）。
// 基础用法
db.AutoMigrate(&User{}, &Order{}, &Product{})
// 带迁移选项
db.Set("gorm:table_options", "ENGINE=InnoDB DEFAULT CHARSET=utf8mb4").
AutoMigrate(&User{})AutoMigrate 的核心行为规则：
- 只增不减：不会删除已存在的列或表，即使结构体中已移除该字段。
- 只改不删：可以修改列的数据类型、默认值、注释，但不会删除索引或约束（除非显式指定）。
- 索引自动管理：根据结构体标签
gorm:"index"、gorm:"uniqueIndex"自动创建索引。 - 关联表自动创建：对于
Has Many、Many2Many等关联，会自动创建中间表。
最佳实践： 在开发环境中，每次修改模型后直接调用
AutoMigrate 即可同步；但在生产环境，建议先用 AutoMigrate 做预检，再通过手动 SQL 或专用迁移工具执行变更。
迁移与冒烟回归的关系
在课程标题《DB迁移冒烟GORM冒烟回归》中，“冒烟回归”指的是在数据库迁移完成后，立即执行一组轻量级、快速验证的测试用例，确保迁移没有破坏核心数据访问路径。这种实践将迁移与冒烟测试紧密耦合，形成“迁移即验证”的闭环。
两者的关系可以用下表概括：
| 环节 | 目标 | 典型操作 | 失败后果 |
|---|---|---|---|
| 数据库迁移 | 同步表结构到最新模型 | AutoMigrate / 手动 SQL | 表结构不一致，应用启动失败 |
| 冒烟回归 | 验证核心 CRUD 路径正常 | 插入一条记录、查询、更新、删除 | 迁移后数据访问异常未被及时发现 |
| 迁移 + 冒烟 | 结构变更后立即确认可用性 | 迁移脚本后紧跟冒烟测试套件 | 问题在 CI/CD 早期暴露，避免流入生产 |
常见误区： 很多团队只做迁移不做冒烟回归，导致“表结构看起来对了，但查询报错”的情况。例如：字段类型从
int 改为 bigint 后，ORM 映射正常，但已有数据中的 NULL 值导致查询 panic。冒烟回归能第一时间捕获这类问题。
本章小结
- 数据库迁移是管理表结构版本化的核心手段，GORM 的
AutoMigrate提供了一种声明式、低成本的迁移方式。 - AutoMigrate 遵循“只增不减”原则，适合开发/测试环境，生产环境需谨慎使用。
- 迁移与冒烟回归是强关联的实践：迁移改变结构，冒烟回归验证结构变更后的可用性，两者结合形成“变更即验证”的闭环。