internal的一个非常有趣的用法(internal member当然仅限于声明它的程序集)是在某种程度上从它获得“好友”功能。友成员是仅对声明它的程序集之外的某些其他程序集可见的对象。c#没有内置对friend的支持，但是CLR有。

可以使用InternalsVisibleToAttribute来声明友程序集，并且来自友程序集中的所有引用将在友程序集中的范围内将声明的程序集的内部成员视为公共成员。这样做的一个问题是所有内部成员都是可见的;你不能挑三拣四。

InternalsVisibleTo的一个很好的用途是将各种内部成员暴露给单元测试程序集，从而消除了测试这些成员所需的复杂反射工作。所有内部成员都可见并不是什么大问题，但是采用这种方法确实会严重破坏类接口，并且可能会破坏声明程序集中的封装。

请记住，当有人查看您的项目名称空间时，任何定义为public的类都会自动显示在智能感知中。从API的角度来看，只向项目的用户展示他们可以使用的类是很重要的。使用internal关键字隐藏他们不应该看到的东西。

如果项目A的Big_Important_Class打算在项目外部使用，那么不应该将其标记为内部。

然而，在许多项目中，经常会有一些实际上只打算在项目中使用的类。例如，您可能拥有一个类，该类保存参数化线程调用的参数。在这些情况下，您应该将它们标记为内部的，如果没有其他原因，只是为了保护自己不受意外的API更改的影响。

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

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

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

在“使用尽可能严格的修饰符”规则的驱动下，我在需要访问的任何地方都使用internal，比如，从另一个类中访问方法，直到我显式地需要从另一个程序集访问它。

由于程序集接口通常比类接口的总和更窄，所以我在很多地方使用它。

其思想是，当您设计一个库时，只有打算从外部(由库的客户端)使用的类应该是公共的。这样你就可以隐藏

可能在未来的版本中更改(如果它们是公开的，您将破坏客户端代码) 对客户是无用的，可能会造成混乱 不安全(所以使用不当会严重破坏你的库)

etc.

如果你在开发内部解决方案，那么使用内部元素就不是那么重要了，因为通常客户会经常与你联系，并且/或访问代码。不过，它们对库开发人员来说相当重要。

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

来自MSDN(通过archive.org):

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

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

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