Dapper.QueryAsync比EF Core.FindAsync/ToListAsync更快且内存更优；前者直接调用SqlDataReader.ReadAsync，无状态跟踪和表达式解析开销，高频单查快1.8–2.2倍，批量查询快60%–90%，大数据流下内存占用低，高并发时GC压力小。
异步方法调用：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 不感知其内部事务管理协议。
微软 Outlook 邮箱和日历管理工具（支持世纪互联版 Office 365）。用于查看、发送、搜索邮件，管理日历日程，创建会议，查询忙闲状态。注意：此功能仅支持世纪互联（21Vianet）版 Microsoft 365，使用 login.chinacloudapi.cn。
- 正确做法：显式控制连接生命周期，用
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 生命周期更长，反而对池大小不那么苛刻。调优前先确认这个底座是否稳住。
