内部类使您能够限制程序集的API。这有很多好处，比如让你的API更容易理解。

此外，如果程序集中存在错误，修复程序引入破坏性更改的可能性就会降低。如果没有内部类，您将不得不假设更改任何类的公共成员都将是破坏性的更改。对于内部类，您可以假设修改它们的公共成员只会破坏程序集的内部API(以及InternalsVisibleTo属性中引用的任何程序集)。

我喜欢在类级和程序集级进行封装。有一些人不同意这一点，但很高兴知道功能是可用的。

当你的类或方法不完全符合面向对象范式，它们做危险的事情，需要从你控制下的其他类和方法调用，而你不想让其他人使用它们时。

public class DangerousClass {
    public void SafeMethod() { }
    internal void UpdateGlobalStateInSomeBizarreWay() { }
}

内部类使您能够限制程序集的API。这有很多好处，比如让你的API更容易理解。

此外，如果程序集中存在错误，修复程序引入破坏性更改的可能性就会降低。如果没有内部类，您将不得不假设更改任何类的公共成员都将是破坏性的更改。对于内部类，您可以假设修改它们的公共成员只会破坏程序集的内部API(以及InternalsVisibleTo属性中引用的任何程序集)。

我喜欢在类级和程序集级进行封装。有一些人不同意这一点，但很高兴知道功能是可用的。

我发现内部被过度使用了。您真的不应该只向某些类公开某些功能，而不向其他使用者公开。

在我看来，这打破了界面，打破了抽象。这并不是说永远不应该使用它，而是更好的解决方案是重构到不同的类，或者在可能的情况下以不同的方式使用。然而，这并不总是可能的。

The reasons it can cause issues is that another developer may be charged with building another class in the same assembly that yours is. Having internals lessens the clarity of the abstraction, and can cause problems if being misused. It would be the same issue as if you made it public. The other class that is being built by the other developer is still a consumer, just like any external class. Class abstraction and encapsulation isnt just for protection for/from external classes, but for any and all classes.

另一个问题是，许多开发人员会认为他们可能需要在程序集中的其他地方使用它，并将其标记为内部，即使他们当时并不需要它。另一个开发商可能会认为它就在那里。通常，在有明确的需要之前，您希望将其标记为私有。

但其中有些可能是主观的，我并不是说永远不应该使用它。只在需要的时候使用。

您希望从同一程序集中的许多其他类中访问，但希望确保其他程序集中的代码不能访问的实用程序或帮助程序类/方法。

来自MSDN(通过archive.org):

内部访问的一个常见用途是在基于组件的开发中，因为它允许一组组件以私有的方式进行合作，而不会向其余应用程序代码公开。例如，用于构建图形用户界面的框架可以提供Control和Form类，它们使用具有内部访问权限的成员进行合作。因为这些成员是内部的，所以它们不会暴露给使用框架的代码。

还可以使用内部修饰符和InternalsVisibleTo程序集级别属性来创建“友程序集”，这些程序集被授予对目标程序集内部类的特殊访问权。

这对于创建单元测试程序集非常有用，然后允许这些程序集调用要测试的程序集的内部成员。当然，没有其他程序集被授予这种级别的访问权限，所以当您发布系统时，将维护封装。

使用internal的另一个原因是混淆了二进制文件。混淆器知道打乱任何内部类的类名是安全的，而公共类的名称不能打乱，因为这可能破坏现有的引用。