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

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

etc.

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

这个怎么样:通常建议不要向程序集的外部用户公开List对象，而是公开IEnumerable对象。但是在程序集中使用List对象要容易得多，因为您可以获得数组语法和所有其他List方法。因此，我通常有一个内部属性，公开要在程序集中使用的List。

欢迎对这种方法提出意见。

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

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

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

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

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

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

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

如果Bob需要BigImportantClass，那么Bob需要让拥有项目A的人注册，以保证BigImportantClass将被编写以满足他的需求，测试以确保它满足他的需求，被记录为满足他的需求，并且将设置一个过程以确保它永远不会被更改，从而不再满足他的需求。

如果一个类是内部的，那么它就不需要经过这个过程，这为项目a节省了预算，他们可以把这些钱花在其他事情上。

内在的意义并不在于它让鲍勃的生活变得困难。而是它允许您控制Project A在特性、生命周期、兼容性等方面做出的昂贵承诺。