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