另一个我认为没有被其他答案涵盖的微妙之处是，当你有一个同名的类和命名空间时。

当您在名称空间中导入时，它将找到该类。如果导入在命名空间之外，那么将忽略导入，并且类和命名空间必须完全限定。

//file1.cs
namespace Foo
{
    class Foo
    {
    }
}

//file2.cs
namespace ConsoleApp3
{
    using Foo;
    class Program
    {
        static void Main(string[] args)
        {
            //This will allow you to use the class
            Foo test = new Foo();
        }
    }
}

//file3.cs
using Foo; //Unused and redundant    
namespace Bar
{
    class Bar
    {
        Bar()
        {
            Foo.Foo test = new Foo.Foo();
            Foo test = new Foo(); //will give you an error that a namespace is being used like a class.
        }
    }
}

这个主题已经有了一些很好的答案，但我觉得我可以用这个额外的答案带来更多的细节。

首先，请记住带有句点的命名空间声明，如：

namespace MyCorp.TheProduct.SomeModule.Utilities
{
    ...
}

完全等同于：

namespace MyCorp
{
    namespace TheProduct
    {
        namespace SomeModule
        {
            namespace Utilities
            {
                ...
            }
        }
    }
}

如果您愿意，可以在所有这些级别上使用指令。（当然，我们只想在一个地方使用，但根据语言的不同，这是合法的。）

解析隐含类型的规则可以大致如下：首先在最内部的“范围”中搜索匹配项，如果没有找到匹配项，则从一个级别转到下一个范围，然后在那里搜索，依此类推，直到找到匹配项。如果在某个级别上找到多个匹配项，如果其中一个类型来自当前程序集，请选择该类型并发出编译器警告。否则，放弃（编译时错误）。

现在，让我们在两个主要约定的具体示例中明确这意味着什么。

（1） 外部使用：

using System;
using System.Collections.Generic;
using System.Linq;
//using MyCorp.TheProduct;  <-- uncommenting this would change nothing
using MyCorp.TheProduct.OtherModule;
using MyCorp.TheProduct.OtherModule.Integration;
using ThirdParty;

namespace MyCorp.TheProduct.SomeModule.Utilities
{
    class C
    {
        Ambiguous a;
    }
}

在上面的例子中，为了找出Ambiguous是什么类型，搜索按以下顺序进行：

C内部的嵌套类型（包括继承的嵌套类型）当前命名空间MyCorp.TheProduct.SomeModule.Utilities中的类型命名空间MyCorp.TheProduct.SomeModule中的类型MyCorp.TheProduct中的类型MyCorp中的类型空命名空间（全局命名空间）中的类型System、System.Collections.Generic、System.Linq、MyCorp.TheProduct.OtherModule、MyCorp.TheProduct.Other Module.Integration和ThirdParty中的类型

其他约定：

（2） 内部使用：

namespace MyCorp.TheProduct.SomeModule.Utilities
{
    using System;
    using System.Collections.Generic;
    using System.Linq;
    using MyCorp.TheProduct;                           // MyCorp can be left out; this using is NOT redundant
    using MyCorp.TheProduct.OtherModule;               // MyCorp.TheProduct can be left out
    using MyCorp.TheProduct.OtherModule.Integration;   // MyCorp.TheProduct can be left out
    using ThirdParty;

    class C
    {
        Ambiguous a;
    }
}

现在，按以下顺序搜索类型Ambiguous：

C内部的嵌套类型（包括继承的嵌套类型）当前命名空间MyCorp.TheProduct.SomeModule.Utilities中的类型System、System.Collections.Generic、System.Linq、MyCorp.TheProduct、MyCorp.TheProduct.OtherModule、MyCorp.TheProduct.OtherModule.Integration和第三方中的类型命名空间MyCorp.TheProduct.SomeModule中的类型MyCorp中的类型空命名空间（全局命名空间）中的类型

（注意MyCorp.TheProduct是“3.”的一部分，因此在“4.”和“5.”之间不需要。）

结束语

无论您将using放在名称空间声明的内部还是外部，都有可能有人稍后将具有相同名称的新类型添加到其中一个具有较高优先级的名称空间中。

此外，如果嵌套命名空间与类型同名，则可能会导致问题。

将using从一个位置移动到另一个位置总是很危险的，因为搜索层次结构发生了变化，可能会找到另一种类型。因此，选择一个惯例并坚持它，这样你就不必再使用。

默认情况下，VisualStudio的模板将using放在命名空间之外（例如，如果您使VS在新文件中生成新类）。

在外部使用using的一个（微小的）优点是，您可以使用全局属性的using指令，例如[assembly:ComVisible（false）]而不是[assembly:System.Runtime.InteropServices.ComVisible。

---

关于文件范围的命名空间声明的更新

由于C#10.0（从2021开始），您可以避免缩进，并使用以下两种方法之一（惯例1，在外部使用）：

using System;
using System.Collections.Generic;
using System.Linq;
using MyCorp.TheProduct.OtherModule;
using MyCorp.TheProduct.OtherModule.Integration;
using ThirdParty;

namespace MyCorp.TheProduct.SomeModule.Utilities;

class C
{
    Ambiguous a;
}

或（惯例2，内部使用）：

namespace MyCorp.TheProduct.SomeModule.Utilities;

using System;
using System.Collections.Generic;
using System.Linq;
using MyCorp.TheProduct;
using MyCorp.TheProduct.OtherModule;
using MyCorp.TheProduct.OtherModule.Integration;
using ThirdParty;

class C
{
    Ambiguous a;
}

但同样的考虑也适用。

如果源解决方案中使用的默认引用（即“引用”）应该在命名空间之外，而那些“新添加的引用”是一个很好的做法，则应将其放在命名空间内。这是为了区分要添加的引用。

我遇到了一条皱纹（其他答案中没有提到）：

假设您有以下名称空间：

有些东西。其他父级.某些.其他

当您在命名空间Parent之外使用Something.Other时，它指的是第一个（Something.Other）。

但是，如果在该命名空间声明中使用它，它将引用第二个（Parent.Something.Other）！

有一个简单的解决方案：添加“global:：”前缀：docs

namespace Parent
{
   using global::Something.Other;
   // etc
}

根据StyleCop文档：

SA1200:使用方向必须放置在命名空间中

原因C#using指令位于命名空间元素的外部。

规则说明如果将using指令或using别名指令放置在命名空间元素之外，则会违反此规则，除非文件不包含任何命名空间元素。

例如，以下代码将导致两次违反此规则。

using System;
using Guid = System.Guid;

namespace Microsoft.Sample
{
    public class Program
    {
    }
}

但是，以下代码不会导致任何违反此规则的行为：

namespace Microsoft.Sample
{
    using System;
    using Guid = System.Guid;

    public class Program
    {
    }
}

这段代码将干净地编译，没有任何编译器错误。但是，尚不清楚分配的是Guid类型的哪个版本。如果将using指令移到命名空间内部，如下所示，将发生编译器错误：

namespace Microsoft.Sample
{
    using Guid = System.Guid;
    public class Guid
    {
        public Guid(string s)
        {
        }
    }

    public class Program
    {
        public static void Main(string[] args)
        {
            Guid g = new Guid("hello");
        }
    }
}

在包含Guid g=new Guid（“hello”）的行中发现以下编译器错误时，代码失败；

CS0576:命名空间“Microsoft.Sample”包含与别名“Guid”冲突的定义

该代码为System.Guid类型创建一个名为Guid的别名，并使用匹配的构造函数接口创建自己的类型Guid。稍后，代码将创建Guid类型的实例。要创建此实例，编译器必须在Guid的两个不同定义之间进行选择。当using alias指令置于命名空间元素之外时，编译器将选择在本地命名空间中定义的Guid的本地定义，并完全忽略在命名空间之外定义的using alis指令。不幸的是，这在阅读代码时并不明显。

但是，当using alias指令位于命名空间中时，编译器必须在同一命名空间中定义的两种不同的、冲突的Guid类型之间进行选择。这两种类型都提供了匹配的构造函数。编译器无法做出决定，因此会标记编译器错误。

将using alias指令放在命名空间之外是一种不好的做法，因为在这样的情况下，这可能会导致混淆，因为不清楚实际使用的是哪种类型的版本。这可能会导致难以诊断的错误。

在命名空间元素中放置使用别名指令可以消除这一错误源。

多个命名空间

在一个文件中放置多个名称空间元素通常是一个坏主意，但如果这样做了，最好将所有using指令放置在每个名称空间元素中，而不是全局放置在文件的顶部。这将严格限定命名空间的范围，也将有助于避免上述行为。

需要注意的是，当使用放置在命名空间外部的指令编写代码时，在命名空间内移动这些指令时应小心，以确保这不会改变代码的语义。如上所述，在命名空间元素中放置使用别名指令允许编译器在冲突类型之间进行选择，而当指令放置在命名空间之外时，这种选择不会发生。

如何修复违规要修复违反此规则的问题，请在命名空间元素中移动所有using指令和using别名指令。

正如杰佩·斯蒂格·尼尔森（Jeppe Stig Nielsen）所说，这条线索已经有了很好的答案，但我认为这一相当明显的微妙之处也值得一提。

使用在名称空间中指定的指令可以缩短代码，因为它们不需要像在外部指定时那样完全限定。

以下示例之所以有效，是因为类型Foo和Bar都位于同一个全局命名空间Outer中。

假设代码文件Foo.cs：

namespace Outer.Inner
{
    class Foo { }
}

和Bar.cs：

namespace Outer
{
    using Outer.Inner;

    class Bar
    {
        public Foo foo;
    }
}

这可能会省略using指令中的外部命名空间，简称：

namespace Outer
{
    using Inner;

    class Bar
    {
        public Foo foo;
    }
}