dapper 和 entity framework 哪个好

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

Dapper 和 Entity Framework 没有绝对的“哪个好”，只有“哪个更适合你当前这一块代码”。

如果你正在写一个高并发订单查询接口，且模型简单、SQL 稳定、DBA 已经调优好，选

Dapper

；
如果你在开发一个带多层嵌套关系、频繁增删改、需要自动跟踪变更、还要支持未来换数据库的管理后台，

EntityFramework Core

更省力。

什么时候该用 Dapper？看这三点是否全中

不是“想快就用 Dapper”，而是它只在特定场景下真正发挥价值：

你愿意也习惯写
SELECT * FROM Users WHERE Status = @status
这类原生 SQL，而不是用
.Where(u => u.Status == status)
你不需要
context.SaveChanges()
自动识别哪几行改了——每次更新都自己写
UPDATE Users SET ... WHERE Id = @id
你项目里没有或极少用到复杂导航属性（比如
user.Orders.Select(o => o.Items)
），也不依赖懒加载/急加载机制

常见错误现象：团队拿 Dapper 去硬套 EF 的开发节奏——比如先查实体，改几个字段，再拼 UPDATE 语句去更新。结果是代码散、参数易错、事务难控，性能优势反而被抵消。

EF Core 不慢，但慢在你没关对开关

很多人测出 EF Core 比 Dapper 慢 3–5 倍，其实多数是因为默认配置没调：

AsNoTracking()
没加：读多写少的列表页，不跟踪对象状态可提升 20%+ 吞吐用了
Include()
却没
Select()
投影：一次性拉回整张 User 表 + 所有关联表，而实际只要 Name 和 Email 没启用查询缓存：相同 LINQ 表达式重复执行时，EF Core 默认会重新编译 SQL（.NET 6+ 已默认开启，旧版本需确认）

示例对比：

var users = context.Users.AsNoTracking().Select(u => new { u.Id, u.Name }).ToList(); // 快
var users = context.Users.Include(u => u.Orders).ToList(); // 慢，尤其 Orders 有几十条时

Dapper Contrib 是“半自动”陷阱区

有人觉得 Dapper 太手动，就加

Dapper.Contrib

用

Get<user>(1)</user>

或

Update(user)

。但它有几个隐性成本：

所有实体必须加
[Table]
、
[Key]
等特性，且只支持单主键；复合主键、自定义列名映射要额外处理
Update()
是全量更新：哪怕你只改了
Name
，它也会生成
UPDATE Users SET Name=@Name,Email=@Email,Phone=@Phone...
，可能覆盖别人刚改的字段没有脏检查——你传进去一个
User
对象，它不管这个对象是不是刚从 DB 查出来的，直接 UPDATE

所以它适合原型或内部工具，不适合核心业务模块。真要“半自动”，不如用 EF Core 的