gormigrate 测试时数据库状态不一致怎么办
测试里跑 gormigrate 容易出现“迁移成功但表结构不对”“测试用例之间互相污染”——根本原因是没隔离每次测试的数据库状态。它不像内存 sqlite 那样天然可丢弃，postgresql/mysql 实例是共享的。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 每个测试用例前用随机后缀创建独立 schema（PostgreSQL）或 database（MySQL），比如
test_schema_abc123，测试结束立即DROP - 避免复用全局
*gorm.DB，每次测试 new 一个带新连接的实例，连到专属库 - 别在
TestMain里一次性 migrate 全局 DB，那是并发测试崩掉的根源 - 如果用 SQLite 内存模式（
file::memory:?cache=shared），确保每个测试开独立*gorm.DB，否则事务和 migration 会跨测试泄漏
如何让 gormigrate 在测试中跳过已执行的迁移
gormigrate 默认每次调用 Migrate() 都查 migrations 表并跳过已记录的迁移，但测试里常误以为“没执行”其实是“已记录但没生效”，比如手动删了表却没清 migrations 记录。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 测试前主动清空
migrations表：用db.Exec("delete FROM migrations")（注意表名可能被 GORM 自动加前缀） - 改用
migrator.Reset()（v4+ 支持），它会删记录 + 回滚所有 migration 的Up操作（前提是你的Down正确实现） - 别依赖
gormigrate.New()的默认tableName，显式设成测试专用名，比如TableName: "test_migrations"，避免和开发库冲突
测试中 mock gormigrate 的 Up/Down 函数是否可行
不可行。gormigrate 的 Up 和 Down 是函数值，不是接口方法，没法直接 mock；而且迁移逻辑通常直连 DB、建表、改字段，mock 只会让测试失去真实性。
更靠谱的做法：
- 把迁移逻辑拆出纯函数：比如
func createUsersTable(db *gorm.DB) Error，这个函数可单独单元测试（用内存 SQLite + 断言db.Migrator().HasTable("users")） - 在 migration 定义里只调用该函数：
Up: createUsersTable，这样核心逻辑可测，gormigrate 本身只负责调度 - 避免在
Up里写业务逻辑（如插入种子数据），那应该放在测试 setup 里，而不是迁移里
使用 gormigrate v4 迁移时测试报 “Error 1050: Table ‘xxx’ already exists”
v4 默认开启 UseTransaction，但 MySQL 8.0.13+ 对 DDL（如 CREATE TABLE）不支持事务回滚，导致测试失败后表残留，下次再跑就撞名。
解决方式很直接：
- 测试环境初始化时显式关掉事务：
gormigrate.New(db, gormigrate.DefaultOptions, migrations)→ 改成gormigrate.Options{UseTransaction: false} - 或者换用 PostgreSQL，它的 DDL 在事务里是真正可回滚的（v4 默认事务对 PG 是安全的）
- 检查迁移定义里有没有漏写
Down，v4 要求每个Up必须配Down，否则Reset()会 panic，影响测试 teardown
测试最麻烦的从来不是写迁移，而是让每次运行都面对一张白纸。schema 隔离、migrations 表清理、DDL 事务限制——这三处不盯紧，测得越勤崩得越准。