Dapper轻快稳活但需手动写SQL：体积小、性能近原生、自动缓存执行计划、零配置映射；缺点是无编译检查、无变更跟踪和LINQ支持、维护成本高；适合微服务、高并发、成熟数据库等场景，不适合模型频繁变动或缺乏SQL能力的团队。
Dapper的优点：轻、快、稳、活
它体积小，核心就一个SqlMapper.cs，没多余依赖；性能接近手写ADO.NET，基准测试显示只比原生SQL慢约11.7%，比EF Core快50%左右；查询计划自动缓存，参数化SQL能复用执行计划；映射靠字段名直连，零配置开箱即用；支持原生SQL、存储过程、多结果集、动态类型，灵活性强。
Dapper的缺点：得自己多盯两眼
没有EF那样的强类型编译检查，改了数据库字段但忘了改SQL，运行时才报错；不带变更跟踪、懒加载、LINQ To SQL这些高级功能，复杂业务逻辑得手动组织；写SQL多了容易分散在各处，维护成本上升；对新手来说，少了ORM的“安全感”，需要更扎实的SQL功底和单元测试习惯。
Dapper适合这样用
• 微服务或小型项目：每个服务独立数据访问，不需要EF那种重上下文管理
• 高并发/低延迟场景：比如实时报表、订单查询、API网关后端
• 已有成熟数据库结构的系统：表设计稳定，SQL可高度优化，不频繁变模型
• 需要精细控制SQL的场合：复杂联查、窗口函数、分页优化、读写分离路由等
• 多数据库兼容需求：MySQL、SQL Server、SQLite、Oracle都能一套代码跑起来
不适合硬套Dapper的情况
• 业务模型极不稳定，天天加字段删表，又没配套SQL检查机制
• 团队缺乏SQL能力，且不愿补单元测试，靠“试出来”改bug
• 需要大量一对多自动展开、级联保存、影子属性等EF专属能力
• 项目已重度依赖EF的迁移（Migrations）和设计器，改造成本远超收益
