golang如何实现数据库迁移_golang数据库迁移实现方法-Golang-PHP中文网

最稳方案是用 github.com/golang-migrate/migrate：它不绑定 ORM，支持多数据库，提供原子执行、版本控制与幂等上下迁移；而 GORM AutoMigrate 仅适合本地开发，不可用于生产迁移。

golang如何实现数据库迁移_golang数据库迁移实现方法

golang 中用 `migrate` 做 SQL 迁移最稳

直接上结论：别手写迁移逻辑，用 migrate（github.com/golang-migrate/migrate）是当前 Go 生态最成熟、生产环境验证最多的方案。它不绑定 ORM，支持 PostgreSQL / MySQL / SQLite / CockroachDB 等主流驱动，且能处理 up/down、版本锁定、状态检查等真实需求。

常见错误是试图用 sql.DB + 自定义版本表 + 手动执行 SQL 文件——容易漏锁、并发出错、回滚不一致。而 migrate 内置 migration 表（如 migrations）、带事务的原子执行、以及幂等的 up/down 控制，省掉大量边界判断。

CLI 工具可直接运行：migrate -database "mysql://user:pass@tcp(127.0.0.1:3306)/mydb" -path ./migrations up
嵌入代码时用 migrate.New + schema.Driver（如 mysql.New），注意传入的 *sql.DB 必须已启用 SetMaxOpenConns(1)，否则多连接可能破坏迁移顺序
SQL 文件名必须严格匹配 YYYYMMDDHHIISS_.up.sql 或 .down.sql，比如 20240520103000_add_users_table.up.sql，时间戳决定执行顺序

为什么不用 `gorm` 内置的 `AutoMigrate`

AutoMigrate 不是迁移工具，它是“按结构体定义同步表结构”的一次性适配器，不能记录历史、无法 down、不支持字段重命名或数据迁移。上线后一旦模型改了，再跑一遍可能删列、丢数据，且无法审计变更路径。

典型误用场景：把 AutoMigrate 当成部署脚本，结果预发环境跑了两次，线上字段被意外删除；或者想加个非空约束，但没默认值，AutoMigrate 直接报错中断。

AutoMigrate 适合本地开发快速建表，不适合 CI/CD 或多环境一致性保障
它不生成 SQL 日志，调试困难；也不支持跨大版本升级（如从 v1.2 到 v2.0 的 schema 拆分）
如果非要用 GORM，建议只用它执行 migrate 生成的 SQL，而不是依赖 AutoMigrate 自动生成

如何安全地在生产环境执行 down 迁移

down 不是“撤销”，而是“按约定退回一个版本”，前提是你的 .down.sql 文件真正可逆。很多团队写了 up 却没写 down，或 down 里用了 DROP COLUMN 这种不可逆操作——这会让 migrate down 变成高危动作。

Golang Uber Dig

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

下载

真实约束比想象中多：MySQL 8.0+ 对 DROP COLUMN 加了元数据锁，可能阻塞线上查询；PostgreSQL 的 ALTER TABLE ... DROP COLUMN 会锁全表。所以 down 脚本必须显式测试过，且最好只用于预发环境。

down 文件必须存在且语法正确，否则 migrate 会报错退出，不会自动跳过
执行前务必备份：用 mysqldump 或 pg_dump 导出当前表数据，尤其含业务关键字段的表
禁止在 down 中做数据清理（如 DELETE FROM orders WHERE status = 'draft'），这类逻辑应拆到应用层，由发布流程单独触发

自定义驱动或 hook 的坑：别在 `post_*` 钩子里连新 DB

migrate 支持 post_up / post_down 钩子，常被用来触发缓存刷新或发通知。但有人在钩子里 new 一个 sql.DB 去查刚改完的表——这极可能失败，因为 migrate 事务尚未提交（PostgreSQL）或隔离级别导致读不到最新数据（MySQL REPEATABLE READ）。

更隐蔽的问题是连接池复用：钩子函数里用的 *sql.DB 如果和迁移用的是同一个实例，可能干扰内部事务状态。