微软文档示例未释放SqlCommand是否符合开发最佳实践？

这个微软文档示例的写法不属于推荐的开发最佳实践，只是旧文档为了简化代码做的省略处理，生产环境代码不要照搬。

具体说明 #

• 很多老版本.NET的示例代码不释放SqlCommand，本质是早期.NET Framework里SqlCommand自己持有的非托管资源非常少，核心资源都绑在关联的SqlConnection和执行生成的SqlDataReader上，写示例的人觉得反正外层连接、读取器都会被using释放，SqlCommand那点托管内存等GC扫到回收就行，不会出大问题。
• 但从开发规范和实际踩坑经验来说，只要一个类型实现了IDisposable接口，就说明它存在需要显式清理的资源场景。经过多版本.NET迭代，SqlCommand内部已经新增了命令执行缓存、参数对象句柄、结果集残留引用这类逻辑，如果不显式释放，极端场景下会出现连接池资源被无效占用、GC回收压力升高的问题；如果不是示例里这种用完马上销毁连接的简单场景，比如缓存SqlCommand复用、执行命令后未读全结果就跳转逻辑，不释放SqlCommand很容易触发难以排查的连接占用、内存泄漏问题。

符合最佳实践的写法 #

给SqlCommand也套上using块即可，不需要额外编写其他释放逻辑：

private static void ReadOrderData(string connectionString)
{
    string queryString =
        "SELECT OrderID, CustomerID FROM dbo.Orders;";
    using (SqlConnection connection = new SqlConnection(connectionString))
    {
        using (SqlCommand command = new SqlCommand(queryString, connection))
        {
            connection.Open();
            using(SqlDataReader reader = command.ExecuteReader())
            {
                while (reader.Read())
                {
                    Console.WriteLine(String.Format("{0}, {1}", reader[0], reader[1]));
                }
            }
        }
    }
}

不要赌某个IDisposable实现“内部没什么资源要释放所以不用using”：只要你是某个IDisposable对象的持有者，用完就用using包裹释放，是永远不会踩坑的通用准则。旧文档里省略using的写法，只是为了减少嵌套、突出核心逻辑做的简化，不代表是规范写法。

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