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

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

etc.

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

当您有方法、类等需要在当前程序集范围内访问，而不能在当前程序集范围外访问时。

例如，一个DAL可能有一个ORM，但对象不应该暴露给业务层，所有交互都应该通过静态方法完成，并传递所需的参数。

唯一一件事我曾经使用内部关键字是许可证检查代码在我的产品;-)

根据经验，有两种成员:

公共表面:从外部组件可见(公共的、受保护的和内部受保护的): 调用者不受信任，因此需要参数验证、方法文档等。 私有表面:从外部程序集(私有和内部或内部类)中不可见: 调用者通常是可信的，所以参数验证、方法文档等可以省略。

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

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

internal关键字的一个用途是限制程序集用户对具体实现的访问。

如果您有一个工厂或其他用于构造对象的中心位置，则程序集的用户只需处理公共接口或抽象基类。

此外，内部构造函数允许您控制实例化公共类的位置和时间。