Dapper适合高并发简单查询，EF Core适合复杂关系与变更跟踪；选型取决于场景而非绝对优劣。
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 倍，其实多数是因为默认配置没调：
AI 舌诊面诊问诊医疗系统 + 诊疗商城系统源码是一套结合 AI 辅助诊断与商品转化的健康类程序，基于浩创云、ThinkPHP（PHP）开发，支持微信服务号与 H5 端，适合做中医舌诊面诊问答、健康建议推送以及配套诊疗商品的运营。
-
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 的 Attach() + Entry().Property().IsModified = true，控制更精确。
关键点往往藏在交接处：比如你用 Dapper 做查询，但用 EF Core 做写入——这种混合模式很常见，也完全可行，但要注意连接字符串、事务隔离级别、甚至时间类型（datetime2 vs datetime）是否一致。这些细节不报错，但某天数据对不上时，很难溯源。
