类中存储ConnectionString优化：用SqlConnection替代字符串可行吗？

我有一个类，初始化时传入连接字符串，类内多个函数通过它访问对应SQL数据库。目前我将传入的ConnectionString存储为私有只读字符串。

当我在函数中无数次编写如下using语句时：

using (SqlConnection SQLCon = new SqlConnection(_ConnectionString))

我开始思考几个问题：

• 将ConnectionString存储为私有只读SqlConnection对象而非字符串形式是否更优？我猜测这样能多次节省SqlConnection实例化的开销，但会比字符串占用更多内存？
• 这是否对连接池和后台垃圾回收过程有好处？
• 无论连接池和GC是否受益，这种方式确实更优吗？
• 如果这么做，使用using语句来使用连接仍有意义吗？还是直接每次调用.Open()和.Close()更合适？比如下面这种写法：

using(_SqlCon)
{
   _SqlCon.Open();
   ...
}

• 不要将SqlConnection作为类成员存储，保留连接字符串的方式才是最优选择
  SqlConnection实例本身是轻量级对象，实例化它的开销可以忽略不计。相反，长期持有一个类级别的SqlConnection会带来诸多问题：

  • 连接池的核心逻辑是基于连接字符串复用空闲连接：当你调用Open()时，连接池会匹配并返回可用连接；调用Close()或Dispose()时，连接会被放回池而非真正关闭。如果长期持有一个SqlConnection，会占用连接池中的一个连接资源，导致其他请求无法复用，反而降低连接池的效率。
  • 长期持有的SqlConnection可能因网络波动、数据库超时等原因变为无效状态，后续调用Open()会直接抛出异常，而每次新建连接的方式能自动从连接池获取有效连接，避免这类问题。

• 对连接池和GC的影响

  • 连接池：持有单个SqlConnection会破坏连接池的复用机制，属于反模式，对连接池毫无益处。而每次通过连接字符串新建SqlConnection并在using中释放，是连接池设计的最佳实践，能最大化连接复用效率。
  • GC：SqlConnection实现了IDisposable接口，using语句会自动调用Dispose()，及时将连接放回连接池，同时释放相关非托管资源。如果长期持有SqlConnection，若未手动正确调用Close()/Dispose()，可能导致非托管资源无法及时释放，增加GC负担，甚至引发连接泄漏。

• 关于using语句的意义
  如果你真的持有了类级别的SqlConnection，绝对不能使用using(_SqlCon)——因为using语句执行完毕后会调用Dispose()，此时该SqlConnection对象会被标记为已销毁，后续再使用会抛出ObjectDisposedException。即便改为手动调用Open()和Close()，依然存在连接池效率低下、连接易失效的问题。

  而标准的using (SqlConnection conn = new SqlConnection(_connStr))写法才是最稳妥的：using能确保无论是否发生异常，连接都会被正确释放（放回连接池），避免资源泄漏；同时连接池会自动处理连接的复用，完全不需要担心实例化的开销问题。

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