Dapper 的 Query 是对 ExecuteReader 的安全、自动、类型化封装。它基于 IDbConnection 扩展，自动管理连接、命令、读取、映射、异常和资源释放；所有 Query 系列方法（Query/QuerySingle/QueryMultiple/QueryAsync 等）底层均调用 ExecuteReader，仅封装了“怎么读、怎么转、怎么收”，无需手动操作 reader。

Dapper 的 ExecuteReader 并不是它对外暴露的公开 API，而是它内部调用 ADO.NET 底层时真正使用的原生方法；而 Query 是 Dapper 封装后提供给开发者的高层方法，本质就是对 ExecuteReader 的安全、自动、类型化封装。

Query 是 ExecuteReader 的“智能包装”

Dapper 不重写 ADO.NET，而是基于 IDbConnection 做扩展。当你调用：

  • connection.Query("SELECT * FROM Users") —— Dapper 内部会：打开连接（如未开启）、创建命令、调用 command.ExecuteReader()、逐行读取、自动映射字段到 User 属性、处理 null 值和类型转换、最后释放 reader。
  • 你手动写 command.ExecuteReader() 则需自己管理生命周期、手动赋值、处理异常、关闭 reader —— 容易出错且重复。

Query 支持多种返回形态，底层都走 ExecuteReader

无论你用的是：

  • Query() → 映射为强类型列表
  • QuerySingle() 或 QueryFirstOrDefault() → 只读一行，仍靠 reader.NextResult() 和 reader.Read() 控制
  • QueryMultiple() → 一次执行多个语句，背后是 SqlDataReader.NextResult() 多次切换结果集
  • 甚至 Query() → 也是用 reader.GetSchemaTable() + 反射动态构建 ExpandoObject

所有这些，Dapper 都没绕开 ExecuteReader，只是把“怎么读、怎么转、怎么收”全帮你做了。

为什么你不该直接调用 ExecuteReader？

不是不能，而是没必要，还容易踩坑：

  • Dapper 的 Query 自动处理连接状态（比如自动打开已关闭的连接）
  • 自动适配参数化查询（@Id → SqlParameter 绑定），手写 SqlCommand 容易漏转义
  • 内置异步支持（QueryAsync 对应 ExecuteReaderAsync），手动实现要处理 Task 调度和上下文同步
  • 多结果集、多映射（如 GridReader）、自定义类型处理器（TypeHandler）等高级能力，全依赖对 reader 的统一抽象

想看底层？可以简单窥探

如果你真想验证，用反编译工具打开 Dapper.dll，搜 QueryImpl 方法，会看到类似逻辑：

using (var reader = cmd.ExecuteReader()) { while (reader.Read()) { ... mapper(reader); } }

—— 这就是 Query 的心脏，干净、直接、不绕弯。

基本上就这些。