为什么需要专门选型
在 Go 项目里，数据库迁移（database migration）往往不是第一项被认真对待的基础设施。很多团队最初依赖 ORM 自带的 AutoMigrate，或者手工在测试环境执行 SQL。直到数据库字段改动引发了一次线上事故，大家才意识到：需要一个明确的、可回放的、能进入代码审查的迁移机制。
Go 生态中比较常见的三个数据库迁移工具分别是 golang-migrate、goose 和 atlas。它们都解决了“用代码管理 Schema 演变”的问题，但三种工具的假设完全不同：一个偏向文件流，一个偏向可编程迁移，另一个偏向声明式状态管理。选型如果只看 star 数，很容易在后续使用时发现流程上不匹配。
golang-migrate：老牌文件流
golang-migrate 是很多 Go 项目最先接触到的迁移工具。它把每一段变更保存为带有序号的 SQL 文件，例如 000001_create_users.up.sql 与 000001_create_users.down.sql。工具通过一张 schema_migrations 表记录当前已经执行的版本，启动时按顺序应用未执行的迁移。
这种模型非常直观：所有迁移都是纯文本，可审查，可复制到其他环境执行。它还提供了 migrate CLI 以及可以被 Go 应用直接 import 的 library 支持，数据库适配非常多。问题在于，当你的业务逻辑开始和数据库变更纠缠在一起，比如一次数据清洗需要根据现有表做复杂计算，纯 SQL 文件就会变得难以维护。此时你需要一种更贴近应用代码的迁移方式。
goose：灵活、可控的迁移运行器
goose 最初来自于 Ruby 生态中的实践经验，后来在 Go 社区广泛使用。它保留了基于文件的版本顺序，但允许每个迁移使用两种实现：一种是普通的 SQL，另一种是 Go 函数。你可以在 up 函数里用 database/sql 执行任意 Go 代码，然后在 down 函数里编写反向逻辑。这对处理数据回填、批量更新、调用外部接口等场景非常有用。
goose 也会维护一个版本表（默认是 goose_db_version），支持事务和回滚。对于熟悉 SQL 又需要灵活性的团队，goose 比 golang-migrate 更顺手。但它的代价是：Go 函数迁移让“迁移即代码”的同时，也让迁移文件变得不可直接复用，比如换一个语言实现的客户端就无法直接读取这些迁移了。
atlas：面向声明的 Schema 治理
atlas 是一套更现代的数据库 Schema 管理工具，它不再只盯着“增量文件”，而是让你定义期望达到的最终状态。你可以在 HCL 或 SQL 中描述一个 Schema 应有的表、索引、约束，atlas 会连接一个开发数据库，自动和你当前状态做 diff，并生成增量迁移 SQL。
这种做法带来两个直接价值：一是可以在 CI 中自动检测 Schema 漂移，确保新环境部署出的数据库结构与预期完全一致；二是减少手写 DDL 的负担，尤其是创建多个外键或者调整索引时，人工容易遗漏细节。atlas 也支持传统版本迁移模式，能生成带版本号的迁移文件，并存入 migrations 目录，方便代码评审和审计。
一张表看懂三者的边界
为了更直观地判断，我把三者最关键的差异整理成一个多维度的对比。注意，这里不是要比出“最好”，而是让你明白哪个维度最贴近自己团队的痛点。
| 维度 | golang-migrate | goose | atlas |
|---|---|---|---|
| 核心模型 | 顺序 SQL 文件 | SQL + Go 函数 | 声明式状态 + 版本迁移 |
| 回滚能力 | 弱，需手写 Down 文件 | 较好，支持内置 Down | 依赖生成版本，支持回滚 |
| Schema Diff | 无 | 无 | 有，可自动生成 DDL |
| 数据库适配 | 非常多 | 较多 | 主流数据库，版本有要求 |
| 适合场景 | 快速起步、纯 SQL | 需代码迁移逻辑 | 多环境、schema 治理要求高 |
从表格可以看出，golang-migrate 和 goose 的起点都是一系列“增量脚本”，而 atlas 的起点是一份完整的 Schema 定义。选型的核心问题不是“支持多少数据库”，而是“你希望团队用什么方式表述数据库变更”。
一个实际的 atlas 迁移示例
如果你之前只接触过 SQL 迁移工具，第一眼看到 HCL 定义可能会觉得陌生。下面是一段最小化的 atlas Schema 定义，用来创建一张 users 表：
schema "public" {
}
table "users" {
schema = schema.public
column "id" {
type = int
auto_increment = true
}
primary_key {
columns = [column.id]
}
}然后执行 atlas 的 apply 命令，一次完整迁移就完成了。atlas 会根据当前连接的数据库状态，把 diff 结果折算成一段 DDL，并写入迁移记录：
atlas schema apply --to file://schema.hcl --dev-url "sqlite://dev?mode=memory"这个命令看似简单，背后其实是 atlas 比较了本地期望状态和 dev 数据库的默认状态，生成一段可执行的 create table 语句。在实际项目中，你还可以把 --to 指向远程数据库 schema，以此做到环境之间的自动对齐。
绕开这三个常见误区
无论使用哪个工具，有几类错误很容易在工程中反复出现。把这些误区说清楚，比单纯比较功能更有价值。
- 误区一：迁移文件越小越安全。实际上迁移粒度太细会导致执行序列过长，例如每个字段一个迁移文件，最终在大表上触发多次锁表，反而让自动执行的窗口期变得更长。合理的做法是把同一次发布中相关变更合并到单个迁移。
- 误区二：声明式工具能自动处理一切 DDL。atlas 能帮你生成 DDL，但生成的 SQL 是否安全仍然需要人工判断。比如 MySQL 上删除一列或修改索引，在千万行级表上可能会造成长时间锁表，这类问题不能因为“工具自动生成”就跳过 review。
- 误区三：所有 DDL 都可以放进事务里回滚。PostgreSQL 支持事务性 DDL，所以一个迁移里多条语句失败可以整体回滚；但 MySQL 在执行 DDL 时会隐式提交，无法回滚。如果你在 goose 里写了一个包含多条 DDL 的 Go 迁移，中途失败时可能会出现一半生效的状态。因此，Go 迁移中的事务处理必须基于目标数据库的行为来设计。
到底怎么选，以及从哪里开始
选择数据库迁移工具，本质上是在回答三个问题：团队更愿意写 SQL 还是写状态声明？迁移过程是否需要复杂的应用逻辑？多个环境之间的 Schema 一致性由谁来保证？
如果项目刚刚起步，团队成员对 SQL 非常熟练，也没有太多数据清洗需求，golang-migrate 是一个稳妥的选择。你只需要维护一堆 .sql 文件，在 CI 中按序执行，遇到问题也能很容易定位。
如果团队需要把业务逻辑揉进迁移过程，比如从旧表拆出新表、先导入数据再重建索引，goose 的 Go 函数迁移会比其他工具自然得多。注意，使用 goose 时要严格约束“只在迁移中写数据操作”，不要把所有业务代码都塞进去。
如果团队管理着多个数据库环境，经常遇到测试环境和生产环境 Schema 不一致，或者希望用代码生成 DDL 来降低人工误差，atlas 值得认真尝试。建议从单个核心库开始，先在 CI 中运行 atlas migrate diff 和 atlas migrate lint，让漂移检查成为发布流水线的一部分。
最后，无论选择哪一款，都要把迁移文件当成普通代码来评审。数据库变更和普通应用代码一样，也需要走 PR、测试和回滚预案。迁移工具只是把过程规范化，真正决定稳定性的，仍然是团队对数据库变更的重视程度。
一个可行的起点是：先用 golang-migrate 或 goose 跑通版本化流程，等遇到 Schema 漂移或大量 DDL 生成需求时，再评估是否引入 atlas。迁移工具之间并不是完全互斥，你可以把 atlas 生成的 DDL 提交到 golang-migrate 的目录里，由同一个执行器统一管理。
原创文章，作者：fudengji，如若转载，请注明出处：https://fudengji.cn/article/804/