成员设为Public vs Friend+InternalsVisibleTo属性的选型疑问

1. 接口成员设为Public是否合理？ #

首先要明确：接口的成员必须是Public，这是.NET语言（C#/VB.NET）的语法规则。接口的核心作用是定义一组对外的契约，用来规范实现类的行为，所以其成员天生就是为了被外部访问而设计的，设为Public完全合理，甚至是强制要求——你没法把接口成员改成Friend（VB）或internal（C#），编译器会直接报错。

2. Public成员会不会被未授权的外部应用调用？ #

技术上存在可能性，但实际风险要看你的部署场景：

• 如果你的程序集是作为公开类库分发（比如NuGet包），那Public成员就是开放给所有调用方的，这是设计的初衷。
• 如果是独立应用的内部类库（比如桌面APP的组件dll），只要你不把这个dll单独对外分发，外部应用无法直接引用它，自然也就没法调用。
• 注意：.NET的访问修饰符是编译时的访问控制，不是运行时的安全防护。哪怕是Friend/internal成员，只要有人拿到你的dll，通过反射依然可以调用。所以访问修饰符的核心作用是规范代码结构、避免误用，而非阻止恶意访问。

3. 应该选Public还是Friend+InternalsVisibleTo？ #

先纠正一个点：接口成员没法设为Friend，所以如果是接口的话没得选，必须用Public。如果是类的成员（可能你混淆了接口和类的成员设置），则根据设计意图判断：

• 若成员是对外提供的功能契约，必须用Public，这是类库对外暴露能力的方式。
• 若成员只是应用内部程序集之间的协作细节，不想暴露给外部，就用Friend（VB）/internal（C#），再通过InternalsVisibleTo属性授权给应用内的其他信任程序集——这样既保证了内部组件的协作，又不会把细节暴露给外部。

内容的提问来源于stack exchange，提问作者CodeAdze