使用CommandBehavior.CloseConnection不释放SqlConnection是否引发未观测Task异常

问题1：异常是否与未主动释放SqlConnection存在关联？ #

答案是肯定的，该异常和当前的连接、DataReader生命周期管理逻辑直接相关，核心触发原因有两个：

• 你使用的IEnumerable<object>是延迟加载类型，AutoMapper将IDataReader映射为IEnumerable时默认不会立即读取所有数据，只有当你实际遍历这个集合时才会从DataReader中逐行读取。你当前的映射代码虽然写在DataReader的using块内，但如果返回的result在using块结束后才被枚举（比如接口返回IEnumerable后由序列化框架触发遍历、或者后续逻辑延迟遍历），此时DataReader已经被释放，关联的连接已经被CommandBehavior.CloseConnection关闭，就会抛出「连接已关闭」的内层异常。
• 外层的未观察任务异常是因为上述延迟遍历触发的异常没有被上层的try-catch捕获，最终被终结器线程抛出。

问题2：原开发人员的说法是否正确？ #

该说法完全错误，核心错误点有两个：

• 对CommandBehavior.CloseConnection的作用理解不全面：这个参数确实会在DataReader释放时关闭关联连接，但前提是DataReader能正常被创建、且你所有的读取操作都发生在DataReader释放之前。另外当前的GetReader代码本身存在多处缺陷：第一没有主动打开连接的逻辑，ExecuteReaderAsync执行时会隐式触发连接打开，这一步如果出错，还没有返回DataReader的情况下CommandBehavior.CloseConnection根本不会生效，你new出来的SqlConnection没有任何释放逻辑，会直接泄漏。
• 对Sql连接池的机制完全不了解：.NET的SqlClient默认启用连接池，你调用new SqlConnection().Open()时不会直接创建物理连接，而是从连接池中获取空闲的物理连接，调用Close/Dispose时也不会销毁物理连接，只是还给连接池供后续请求复用，所谓「创建SqlConnection耗时耗资源」完全是误解。反而依赖DataReader释放才归还连接的逻辑，很容易因为DataReader生命周期管理不当导致连接长时间被占用，引发连接池耗尽的问题。

修复建议 #

快速修复方案 #

在using块内就将延迟加载的IEnumerable转为立即执行的List，保证所有读取操作在DataReader释放前完成：

using (var datareader = await readerhelper.GetReader(para1, para2))
{
    var result = _mapper.Map<IDataReader, IEnumerable<object>>(datareader).ToList();
}

规范修复方案 #

重构GetReader逻辑，主动用using管理SqlConnection生命周期，不要依赖CommandBehavior.CloseConnection，同时补全连接打开逻辑：

public static async Task<List<object>> GetMappedResult(/*你的参数*/)
{
    using (var conn = new SqlConnection("connString"))
    using (var sqlCommand = new SqlCommand())
    {
        sqlCommand.Connection = conn;
        await conn.OpenAsync();
        using (var sqlDataReader = await sqlCommand.ExecuteReaderAsync())
        {
            return _mapper.Map<IDataReader, IEnumerable<object>>(sqlDataReader).ToList();
        }
    }
}

内容的提问来源于stack exchange，提问作者daxu