EF Core内存数据库怎么用 EF Core InMemory Provider测试教程

来源：这里教程网时间：2026-02-21 17:36:51 作者：

EF Core内存数据库（

InMemory

Provider）不是用来跑生产环境的，它是专为快速、隔离的单元测试设计的轻量级模拟工具。用它，你不用装SQL Server、不用连网络、不依赖Docker容器，几毫秒就能启动一个干净的“假数据库”。

安装与基础配置

先装NuGet包：

dotnet add package Microsoft.EntityFrameworkCore.InMemory
或在Visual Studio中通过NuGet包管理器搜索安装

然后在测试代码里配置DbContext选项：

var options = new DbContextOptionsBuilder<AppDbContext>()
    .UseInMemoryDatabase(databaseName: "TestDb_" + Guid.NewGuid()) // 推荐用唯一名
    .Options;

每次用不同

databaseName

，就得到一个完全独立的内存数据库实例——避免测试间数据污染。

写测试时的关键操作

内存数据库不自动建表，也不执行迁移，所以你得靠代码“手动初始化”数据：

直接调
context.AddRange()
+
context.SaveChanges()
插入测试数据或者封装一个
SeedData(context)
方法，在每个测试前调用不需要
EnsureCreated()
，它对InMemory无效；也不要调
Migrate()
，它不支持迁移

示例：

using var context = new AppDbContext(options);
context.Users.AddRange(
    new User { Id = 1, Name = "Alice" },
    new User { Id = 2, Name = "Bob" });
context.SaveChanges();
var found = context.Users.FirstOrDefault(u => u.Name == "Alice");
Assert.NotNull(found);

注意它的行为边界

它快，但不等于“真实数据库”。以下情况容易踩坑：

不支持JOIN、GROUP BY、子查询等复杂SQL语义——查询会被转成LINQ to Objects执行，结果可能和SQL Server不一致 DateTime默认值不会自动生成：比如
public DateTime CreatedAt { get; set; }
会变成
0001-01-01
，需手动赋值或配
HasValueGenerator<datetimevaluegenerator>()</datetimevaluegenerator>
没有事务回滚能力：
SaveChanges()
后数据就“真存了”，只能靠
context.Database.EnsureDeleted()
清空整个库 不校验外键约束、唯一索引、数据库触发器等——这些逻辑在内存中被跳过