EF Core怎么在运行时应用迁移 EF Core context.Database.Migrate()方法

月夜之吻 2025-12-15 00:00:00 次阅读

EF Core 的 context.Database.Migrate() 可在运行时自动应用待执行迁移，但需依赖 __EFMigrationsHistory 表、要求数据库可创建或已存在，且不支持回滚、生产环境慎用。

EF Core 的 context.Database.Migrate() 方法确实可以在运行时自动应用待执行的迁移，但它有明确的前提和限制，不能简单理解为“一键升级数据库”。

✅ 前提：必须已有迁移历史表（__EFMigrationsHistory）

该方法依赖数据库中是否存在 __EFMigrationsHistory 表，并通过比对表中已记录的迁移 ID 与项目中 Migrations 文件夹下的迁移类来决定执行哪些未应用的迁移。如果这是全新数据库、且从未调用过 Migrate() 或 Update-Database，它会尝试应用所有迁移（包括初始迁移），但前提是上下文能成功创建数据库（例如 SQL Server 允许自动建库，SQLite 默认支持，而 PostgreSQL 需目标数据库已存在）。

✅ 正确使用方式（典型场景）

常见于应用启动阶段，比如在 ASP.NET Core 的 Program.cs 中：

确保 DbContext 已注册到 DI 容器（如 services.AddDbContext(...)）
获取服务后调用 Migrate()，推荐包裹在 try-catch 中并记录日志
避免在高并发或热更新场景下直接调用（迁移是 DDL 操作，可能锁表或失败）

示例：

using (var scope = app.Services.CreateScope())
{
    var context = scope.ServiceProvider.GetRequiredService();
    context.Database.Migrate(); // 应用所有待迁移
}

⚠️ 注意事项和常见陷阱

不支持回滚：Migrate() 只向上应用，无法撤回已执行的迁移（要回退需手动调用 context.Database.Migrate("上一个迁移名") 或用 dotnet ef migrations remove）
生产环境慎用：自动迁移跳过人工审核，容易因迁移脚本错误导致数据丢失或结构异常；建议生产环境使用显式 dotnet ef database update 配合脚本审查
无事务保障（部分数据库）：SQL Server 上每个迁移在一个事务内执行，但 SQLite 和 PostgreSQL 的事务行为受限于驱动和版本，不是所有操作都可回滚
迁移类必须可加载：确保编译后的迁移程序集能被当前上下文访问到（比如类库未引用、发布时遗漏 .dll 等会导致找不到迁移）