datareader是数据库连接上的单向流水线，用完必须关闭，否则阻塞连接；执行executereader()后连接即被独占，后续任何操作都会报“已有打开的datareader”错误。
DataReader 不是通用数据容器，它是数据库连接上的“单向流水线”——用完必须关，关不掉就卡死连接，开多个直接报错。
为什么执行 SqlCommand 时提示“已有打开的 DataReader”
这个错误不是你写了 SqlDataReader 才出现的。只要调用了 ExecuteReader()（哪怕只调了一次、没读完、没 Close），该 SqlConnection 就被独占了。后续任何操作——包括另一个 ExecuteReader()、ExecuteScalar()、甚至同一连接上新建一个 SqlCommand——都会触发该异常。
常见隐藏场景：
- 忘记在
using块里包裹SqlDataReader，或提前return跳出了作用域，导致Close()没执行 - 在循环中反复调用
command.ExecuteReader()，但没把上一个reader.Close()放在循环外 - 使用了
DataTable.Load(reader)后，误以为 reader 已自动释放（它没有） - 异步方法中用了
await command.ExecuteReaderAsync()，但没用await reader.DisposeAsync()（.NET 6+）
SqlDataReader.Read() 返回 false 却没报错，数据去哪了
Read() 返回 false 只代表“没有下一行”，不等于出错。真正的问题常出在三处：
-
HasRows是可选判断，但若 SQL 查询本身没结果（比如 WHERE 条件全不匹配），Read()第一次就返回false，程序直接跳过循环体 - 连接未打开：
connection.Open()被跳过或抛异常后静默吞掉，ExecuteReader()返回空 reader，Read()立即失败 - 字段索引越界：比如用
reader.GetInt32(5)访问只有 3 列的结果集，会抛IndexOutOfRangeException，但若你只检查Read()返回值，异常就被漏掉了 - NULL 值未处理：直接调用
GetXXX()读取可能为 NULL 的列（如reader.GetString(2)），会抛InvalidCastException；必须先用IsDBNull(2)判断
关闭 SqlDataReader 为什么特别慢，甚至超时
reader.Close() 默认会等待服务器返回 RecordsAffected、输出参数等附加信息，对大查询或网络延迟高时极易超时。这不是内存泄漏，是协议级等待。
解决办法很直接：
- 如果不需要
RecordsAffected或输出参数，关之前先调command.Cancel()，再reader.Close() - 改用
using (var reader = cmd.ExecuteReader(CommandBehavior.SequentialAccess))，能减少服务端资源占用 - .NET Core/.NET 5+ 推荐用
await reader.DisposeAsync()替代Close()，它不等待服务端响应 - 绝对不要在
Finalize或Dispose中手动调Close()——using或Dispose()已包含它
SqlDataReader 和 ExcelDataReader 完全是两回事
名字带 “DataReader” 不代表行为一致。SqlDataReader 绑定数据库连接、强类型、只进、必须 Close；而 ExcelDataReader 是纯内存流解析器，不依赖任何连接，IExcelDataReader 实例读完一个 sheet 后调 NextResult() 就能切到下一个，不用 Close 也能继续用——但它也不支持随机访问，仍是逐行推进。
混淆这两者会导致资源管理错乱：有人试图对 ExcelDataReader 调 Close()（它没有这个方法），或对 SqlDataReader 忘记 Close() 导致连接池耗尽。关键区别就一句：SqlDataReader 是数据库协议层的游标，ExcelDataReader 是文件格式解析器——前者管连接，后者管字节流。
