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<User>("SELECT * FROM Users")—— Dapper 内部会：打开连接（如未开启）、创建命令、调用command.ExecuteReader()、逐行读取、自动映射字段到User属性、处理 null 值和类型转换、最后释放 reader。 - 你手动写
command.ExecuteReader()则需自己管理生命周期、手动赋值、处理异常、关闭 reader —— 容易出错且重复。
Query 支持多种返回形态，底层都走 ExecuteReader
无论你用的是：
-
Query<T>()→ 映射为强类型列表 -
QuerySingle<T>()或QueryFirstOrDefault<T>()→ 只读一行，仍靠 reader.NextResult() 和 reader.Read() 控制 -
QueryMultiple()→ 一次执行多个语句，背后是SqlDataReader.NextResult()多次切换结果集 - 甚至
Query<dynamic>()→ 也是用 reader.GetSchemaTable() + 反射动态构建 ExpandoObject
所有这些，Dapper 都没绕开 ExecuteReader，只是把“怎么读、怎么转、怎么收”全帮你做了。
为什么你不该直接调用 ExecuteReader？
不是不能，而是没必要，还容易踩坑：
- Dapper 的
Query自动处理连接状态（比如自动打开已关闭的连接） - 自动适配参数化查询（
@Id→SqlParameter绑定），手写 SqlCommand 容易漏转义 - 内置异步支持（
QueryAsync对应ExecuteReaderAsync），手动实现要处理 Task 调度和上下文同步 - 多结果集、多映射（如
GridReader）、自定义类型处理器（TypeHandler<T>）等高级能力，全依赖对 reader 的统一抽象
想看底层？可以简单窥探
如果你真想验证，用反编译工具打开 Dapper.dll，搜 QueryImpl 方法，会看到类似逻辑：
—— 这就是 Query 的心脏，干净、直接、不绕弯。
基本上就这些。
