protected 只认“是不是子类”，internal 只认“是不是同一个程序集”——它们控制的是两种完全不同的边界。
什么时候该用 protected
？看继承，不看项目
当你希望某个成员能被子类复用、重写，但又不想让外部代码随意调用时，就用
protected。它和程序集无关：子类哪怕在另一个
.dll里，也能访问父类的
protected成员；而同一程序集里的非子类，哪怕离得再近，也碰不到。 常见错误现象：
CS0122：“无法访问受保护的成员”，其实是误以为“同项目 = 能访问”，结果发现不是子类就报错 适用场景：框架基类中预留的钩子方法，比如
protected virtual void OnInitialized()，供下游继承者定制逻辑 注意：
protected字段或属性不能直接被子类的静态上下文访问（比如静态构造函数），必须通过实例或
base调用
什么时候该用 internal
？看程序集，不看继承
internal是“项目内共享”的快捷键。只要在同一个编译产出（
.exe或
.dll）里，任何类——不管有没有继承关系、是不是嵌套类、甚至是不是
private嵌套类的外层——都能直接访问
internal成员。 常见错误现象：把一个
internal class的成员设为
protected，编译直接报错——因为
internal类本身对外不可见，它的
protected没有意义，必须显式写成
internal protected（等价于
protected internal） 适用场景：项目内部通用工具类，比如
internal static class JsonHelper，避免暴露给 NuGet 引用方 性能影响：零成本，纯编译期检查，运行时不产生任何额外开销
protected internal
不是“又 protected 又 internal”，而是“protected 或 internal”
这是最容易误解的一点：
protected internal的访问条件是“满足其一即可”，不是“必须同时满足”。它比
protected更宽（多了同程序集任意类），又比
internal更宽（多了跨程序集子类）。
public class Base
{
protected internal void Log() { /* ... */ }
}
<p>// ✅ 同一程序集，非子类 —— 可调用
class Helper
{
void Use() => new Base().Log();
}</p><p>// ✅ 不同程序集，但继承了 Base —— 也可调用
class Derived : Base
{
void Do() => Log(); // OK
}
别名陷阱：internal protected和
protected internal完全等价，C# 不区分顺序，但建议统一用
protected internal（符合“修饰符强度递增”惯例） 兼容性注意：.NET Framework 4.0+ 和所有 .NET Core/.NET 5+ 都支持，无版本风险 真实坑点：如果你的库公开了
protected internal方法，引用方只要继承你这个类，就能调用它——这等于变相暴露了部分内部契约，设计时要当心
最常被忽略的其实是边界混用：想让子类用，又怕外部项目拿到，结果选了
internal，结果子类一跨程序集就断；或者想让项目内多个模块协作，却用了
protected，结果非子类调不了。关键不是记口诀，而是每次写访问修饰符前，先问自己一句：我到底在防谁？是怕别人继承，还是怕别人引用？
