Azure SQL DB是否推荐单例模式？AddScoped比AddSingleton更合适？

我们使用Azure SQL DB，当前针对每个请求创建、打开并关闭数据库连接，代码示例如下：

// Startup.cs中
builder.Services.AddScoped<IDbConnection>(_ => new SqlConnection(""));
builder.Services.AddScoped<Func<IDbConnection>>(svc => () => svc.GetRequiredService<IDbConnection>());

// clientimpl.cs中
private readonly Func<IDbConnection> _connectionFactory;
using (var connection = _connectionFactory())
{
    // 打开前检查状态
    if (connection.State == ConnectionState.Closed)
        connection.Open();

    // 执行数据库操作...
}
finally
{
    connection.Close();
}

我们考虑改为创建单例SqlConnection实例，在应用生命周期内复用，而非为每个请求创建、开闭连接。现咨询：

1. Azure SQL DB是否推荐单例模式？有哪些注意事项？ #

Azure SQL DB不推荐使用单例SqlConnection实例，核心原因和注意事项如下：

• SqlConnection本身不是线程安全的，单例实例被多请求并发调用时，会出现连接状态混乱、命令执行冲突等问题，直接引发异常或数据错误。
• 即便手动做线程同步，也会造成严重性能瓶颈——所有请求都要排队等待同一个连接，完全浪费了连接池的优势。
• 单例连接长期持有，容易因网络波动、Azure SQL自动维护（如故障转移）等进入失效状态，后续请求会全部失败，且难以自动恢复。

2. builder.Services.AddScoped(_ => new SqlConnection(""))是否比builder.Services.AddSingleton(_ => new SqlConnection(""))更推荐？ #

绝对推荐使用AddScoped注册SqlConnection，理由如下：

• AddScoped会为每个HTTP请求创建独立的连接实例，刚好匹配请求生命周期，从根源避免多线程冲突问题。
• .NET SqlClient底层已实现连接池机制：调用Open()时是从连接池取空闲物理连接，调用Close()/Dispose()时是把连接放回池里复用。你看似每次请求都创建连接，实际开销极低。
• AddScoped的连接是请求隔离的，即便某个连接出问题，也只会影响当前请求，不会扩散到整个应用。
• 补充：你当前代码里的finally块connection.Close()可以去掉，因为using块会自动调用Dispose()，而SqlConnection.Dispose()会自动关闭连接并归还到连接池。

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