Golang数据库迁移工具实现自动Schema同步-Golang-PHP中文网

automigrate不是真正的自动schema同步，因其仅安全补缺（建表、加字段、建索引），不删字段、不改类型、不支持版本管理与回滚；而golang-migrate cli通过成对sql文件、严格序号、状态记录和可逆操作实现可靠版本化迁移。

golang数据库迁移工具实现自动schema同步

用 golang-migrate CLI 做自动 Schema 同步最可靠；AutoMigrate 仅适合开发初期快速建表，不能替代版本化迁移。

AutoMigrate 只做「安全补缺」：建缺失表、加缺失字段、建缺失索引，但不会删字段、不改类型、不删索引、不处理外键约束（除非显式启用），也不感知历史变更。它没有版本号、不记录状态、不支持回滚。

常见失效场景：

把 Name string `gorm:"size:50"` 改成 size:100，MySQL 下大概率不生效，PostgreSQL 直接跳过
字段从 Age int 改成 Age uint，不会触发 ALTER COLUMN
删掉一个 struct 字段后跑 AutoMigrate，原数据库字段还在
PostgreSQL 使用非 public schema（如 my_schema）但 DSN 没带 search_path=my_schema，表建在 public，后续查询报 relation "xxx" does not exist

文件命名、URL 参数、路径写法稍有偏差就会静默失败或报错，不是“没效果”，而是根本没被识别。

迁移文件必须成对存在：000001_create_users.up.sql 和 000001_create_users.down.sql；漏掉 .down.sql 会导致 migrate down 报错
序号必须连续、不可跳号（如 000001 → 000002），否则 up 会跳过中间缺失编号的文件
数据库 URL 必须显式携带驱动所需参数：postgres://... 要加 ?sslmode=disable，mysql://... 要加 ?parseTime=true&loc=Local
SQLite 迁移路径不能用相对路径：file://./migrations 会解析失败，得用绝对路径如 file:///home/user/project/migrations

在服务启动时嵌入迁移逻辑（如 FaaS 或短生命周期任务），最容易因事务/连接池配置出问题。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

migrate.Up() 默认为每个 .up.sql 启一个事务——但 PostgreSQL 的 CREATE TABLE 等 DDL 在函数内执行会报 ERROR: CREATE TABLE cannot be executed from a function
必须提前设置 db.SetMaxOpenConns(1)：多连接并发操作 schema_migrations 表会锁冲突，导致迁移卡死或状态错乱
别传 -1 给 Up()：m.Up(-1) 是无限执行所有未应用迁移，一旦某条失败，后续无法恢复；应只传 0（执行全部）或具体数字

migrate down 不是“撤销上一条 SQL”，而是按序号倒序执行 .down.sql。只要其中一条成功写了记录，就再也不会重试——哪怕它只删了一半外键就崩了。

典型症状：

执行 migrate down 1 报错 ERROR: cannot drop table "users" because other objects depend on it
但 schema_migrations 表里该版本已标记为已回滚
下次 up 直接跳过，导致表结构和迁移脚本长期不一致

解法只有手动清理：DELETE FROM schema_migrations WHERE version = 123456;，再重试 down ——但前提是你知道哪条 down 脚本实际没跑完。

真正安全的做法，是在每个 .down.sql 开头加 DO $$ BEGIN ... EXCEPTION WHEN others THEN NULL; END $$;（PostgreSQL）或等效防御块，避免单点失败阻断整个回滚流。