Revel 框架不内置数据库迁移功能，因其定位为全栈 Web 框架而非 ORM，迁移需借助 GORM、Goose 等第三方工具手动集成，且必须统一使用 revel.AppPath 构建数据库路径以确保一致性。
Revel 框架本身不提供数据库迁移（migration）功能，必须借助第三方库（如 GORM、XORM 或 Goose）手动集成；直接用 revel run 启动时不会自动执行迁移，也不会感知 migrations/ 目录。
为什么 Revel 没有内置 migration 支持
Revel 的定位是全栈式 Web 框架，而非 ORM 框架。它把数据库连接、查询、事务等交由开发者自行选择底层驱动（database/sql）或 ORM（如 GORM），迁移逻辑自然也由这些生态承担。框架只负责注入 c.DB（若配置了 ORM），但不约定“如何建表”“如何版本化变更”。
常见误解是以为 conf/app.conf 中的 db.import 或 db.url 会触发自动迁移——实际上它们仅用于初始化连接，和 schema 管理完全无关。
- Revel 的
app.Init()阶段只做连接池建立、日志绑定等，不扫描或执行迁移文件 - 所有迁移命令（如
goose up、gorm-cli migrate）都需独立运行，与 Revel 进程分离 - 若在控制器中调用迁移函数（如
AutoMigrate），属于运行时行为，无法回滚、易引发并发冲突，不推荐
用 GORM + goose 实现可复用的迁移流程
GORM 是 Revel 生态中最常搭配的 ORM，而 goose 是轻量、SQL 优先的迁移工具，二者组合兼顾可读性与可控性。关键在于：迁移脚本与 Revel 应用解耦，但路径和配置共享。
实操建议：
- 在项目根目录下新建
migrations/，存放20230101120000_init.sql类型的版本化 SQL 文件 - 通过
goose -dir migrations sqlite3 ./data/app.db up手动执行（开发阶段） - 生产部署时，将
goose二进制与应用一起打包，并在启动前加 shell 脚本调用：goose -dir ./migrations sqlite3 $DB_PATH up - 避免在
app.Init()中嵌入迁移逻辑——这会让revel test失败（测试 DB 是内存 SQLite，不应被迁移污染）
在 Revel 控制器中安全触发迁移（仅限开发调试）
某些场景下（如本地快速验证新字段），你可能想通过 HTTP 端点一键迁移。这不是生产方案，但可临时用：
- 路由中加一行：
GET /_migrate APP.Migrate（仅 dev 环境启用） - 控制器里用 GORM 的
AutoMigrate，但必须限定模型范围：db.AutoMigrate(&User{}, &Book{})，不要用空结构体或通配 - 务必检查当前运行模式：
if revel.RunMode != "dev" { return c.RenderError("Migration disabled") } - 注意
AutoMigrate不支持列删除、类型变更等破坏性操作，且无法生成回滚 SQL
容易踩的坑：SQLite 路径错位导致迁移失败
Revel 应用中 SQLite 路径若依赖 runtime.Caller 或 os.Getwd()，迁移命令执行时工作目录可能是 $GOPATH/bin 或 /tmp，导致 ./data/app.db 被创建在错误位置，而控制器连的是另一个路径的 DB。
正确做法是统一使用 Revel 提供的 revel.AppPath 构建绝对路径：
dbPath := filepath.Join(revel.AppPath, "data", "app.db")
os.MkdirAll(filepath.Dir(dbPath), 0755)
gorm.Open(sqlite.Open(dbPath), &gorm.Config{})
这样无论 goose 还是控制器，只要都基于 revel.AppPath 构造路径，就能指向同一份数据库文件。
真正麻烦的不是“怎么写迁移”，而是“让所有环节看到同一个数据库文件”。路径不一致，迁移再准也没用。
