异步方法调用：Dapper.QueryAsync vs EF Core.FindAsync/ToListAsync
Dapper 的
QueryAsync和 EF Core 的
FindAsync、
ToListAsync都是真正的异步 I/O，但底层行为差异很大。Dapper 直接委托给
SqlDataReader.ReadAsync，不涉及状态跟踪或表达式树解析；EF Core 在异步执行前需完成 LINQ 表达式翻译、变更跟踪器介入、以及结果集到实体的深度映射（尤其含导航属性时）。 高频单行查询（如用户登录校验）：用
connection.QueryFirstOrDefaultAsync<user>(sql, param)</user>比
context.Users.FindAsync(id)快约 1.8–2.2 倍（实测于 SQL Server 2022 + .NET 8） 批量列表查询（如分页接口）：Dapper 的
QueryAsync<product>(sql, param)</product>比
context.Products.Where(...).ToListAsync()快 60%–90%，差距随导航属性数量增大而拉大 注意：EF Core 的
AsNoTracking()能缩小差距，但无法消除表达式树编译和实体初始化开销
高并发压测下的连接池与内存表现
在 500+ 并发请求下，两者对
SqlConnection连接池和 GC 压力的影响截然不同。Dapper 因无上下文生命周期管理，每次查询完即释放 reader 和映射对象，对象存活期极短；EF Core 的
DbContext实例若未及时释放（尤其被意外注入为 Singleton），会堆积未提交的变更快照和缓存项，导致 Gen2 GC 频繁触发。 Dapper 推荐搭配
buffered: false处理大数据流，例如导出百万级报表：
connection.QueryAsync<product>(sql, param, buffered: false)</product>—— 内存占用稳定在 ~2MB，而 EF Core 的
ToListAsync()在同样数据量下峰值内存超 1.2GB EF Core 若启用
EnableSensitiveDataLogging或未关闭延迟加载代理（
Microsoft.EntityFrameworkCore.Proxies），高并发时 CPU 花费在动态代理生成上可达 15% 以上 真实线上服务中，Dapper 的
QueryAsync在 QPS 3000+ 时仍保持 P99
事务内混合使用：为什么不要在同一个 DbContext 中混用 Dapper
很多人想“用 EF Core 管事务，用 Dapper 做快查”，但直接传
context.Database.GetDbConnection()给 Dapper 查询，极易引发
InvalidOperationException: The connection is already in use或事务隔离异常——因为 EF Core 的连接可能处于 pending transaction 状态，而 Dapper 不感知其内部事务管理协议。 正确做法：显式控制连接生命周期，用
context.Database.BeginTransaction()获取
DbTransaction，再传给 Dapper 的
QueryAsync(..., transaction: tx)禁止操作：在
using var context = new AppDbContext()作用域内，反复调用
context.Database.GetDbConnection().QueryAsync(...)—— 这会干扰 EF Core 自身的连接复用逻辑 更安全的替代：用 EF Core 执行写操作，Dapper 单独持独立连接做只读查询（需确保事务隔离级别一致，如都设为
ReadCommitted）
性能拐点在哪？看数据规模和查询复杂度
不是“Dapper 总是更快”，而是当查询复杂度上升、数据结构变深时，EF Core 的抽象成本会指数级放大。一个关键拐点是：**单次查询返回实体含 ≥ 2 个非空导航集合（如 Order → OrderItems → Product）**。
简单投影（SELECT id, name FROM users）：Dapper 快 1.3–1.7×，优势稳定 多表 JOIN + 动态 WHERE 条件：Dapper 手写 SQL 更易优化索引覆盖，EF Core 的 LINQ 可能生成冗余字段或强制嵌套循环 JOIN 聚合统计（
GROUP BY + COUNT/DISTINCT/SUM）：Dapper 返回
dynamic或自定义 DTO 更轻量；EF Core 若映射到完整实体，会浪费大量字段反序列化开销 真正要注意的坑：别为了“统一 ORM”强行让 Dapper 去模拟 EF Core 的变更跟踪逻辑，也别用 EF Core 的
FromSqlRaw包裹复杂 SQL 后再映射——这既丢性能又失可控性
实际项目里，最常被忽略的是连接字符串中的
Pooling=true和
Max Pool Size配置。Dapper 对连接池更“敏感”，默认池大小 100 在高并发下容易耗尽；EF Core 因 DbContext 生命周期更长，反而对池大小不那么苛刻。调优前先确认这个底座是否稳住。
