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

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

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

在某些情况下，将类的成员设为内部是有意义的。例如，如果你想控制类的实例化方式;假设您为创建类的实例提供了某种类型的工厂。您可以将构造函数设置为内部的，这样工厂(位于同一个程序集中)就可以创建类的实例，但程序集中之外的代码不能。

然而，如果没有特定的原因，我不认为将类或成员设置为内部的有任何意义，就像没有特定的原因将它们设置为公共的或私有的一样没有意义。

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

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

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

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

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

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

来自MSDN(通过archive.org):

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

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

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

减少噪音，你暴露的类型越少，你的库就越简单。 防篡改/安全性是另一个问题(尽管Reflection可以战胜它)。