总之，当您使用实现IDisposable类型的局部变量时，总是毫无例外地使用using1。

如果使用非局部IDisposable变量，则始终实现IDisposable模式。

两条简单的规则，无一例外。否则，防止资源泄漏是一件非常痛苦的事情。

1):唯一的例外是-当你处理异常时。在finally块中显式调用Dispose的代码可能会更少。

using的另一个重要用途是实例化一个模态对话框。

Using frm as new Form1

    Form1.ShowDialog

    ' Do stuff here

End Using

并不是说它非常重要，而是使用它还可以用来动态地更改资源。

是的，正如前面提到的，是一次性的，但是可能您特别不希望在执行的其余时间内它们与其他资源不匹配。所以你要把它处理掉，这样它就不会影响到其他地方。

当使用ADO时。NET中，你可以在connection对象或reader对象上使用keywork。这样，当代码块完成时，它将自动处理您的连接。

对我来说，“using”这个名字有点令人困惑，因为它可以是一个导入Namespace的指令，也可以是一个用于错误处理的语句(就像这里讨论的那样)。

为错误处理取一个不同的名字会很好，而且可能是一个更明显的名字。

Microsoft documentation states that using has a double function (https://msdn.microsoft.com/en-us/library/zhdeatwt.aspx), both as a directive and in statements. As a statement, as it was pointed out here in other answers, the keyword is basically syntactic sugar to determine a scope to dispose an IDisposable object. As a directive, it is routinely used to import namespaces and types. Also as a directive, you can create aliases for namespaces and types, as pointed out in the book "C# 5.0 In a Nutshell: The Definitive Guide" (http://www.amazon.com/5-0-Nutshell-The-Definitive-Reference-ebook/dp/B008E6I1K8), by Joseph and Ben Albahari. One example:

namespace HelloWorld
{
    using AppFunc = Func<IDictionary<DateTime, string>, List<string>>;
    public class Startup
    {
        public static AppFunc OrderEvents() 
        {
            AppFunc appFunc = (IDictionary<DateTime, string> events) =>
            {
                if ((events != null) && (events.Count > 0))
                {
                    List<string> result = events.OrderBy(ev => ev.Key)
                        .Select(ev => ev.Value)
                        .ToList();
                    return result;
                }
                throw new ArgumentException("Event dictionary is null or empty.");
            };
            return appFunc;
        }
    }
}

这是一种明智的做法，因为滥用这种做法会损害代码的清晰性。在DotNetPearls (http://www.dotnetperls.com/using-alias)中有一个关于c#别名的很好的解释，也提到了优点和缺点。