protected用于子类复用重写，无视程序集边界；internal用于同一程序集内共享，无视继承关系；protected internal表示“protected或internal”任一满足即可，非两者同时满足。
protected 只认“是不是子类”，internal 只认“是不是同一个程序集”——它们控制的是两种完全不同的边界。
什么时候该用 protected？看继承，不看项目
当你希望某个成员能被子类复用、重写，但又不想让外部代码随意调用时，就用 protected。它和程序集无关：子类哪怕在另一个 .dll 里，也能访问父类的 protected 成员；而同一程序集里的非子类，哪怕离得再近，也碰不到。
- 常见错误现象：
CS0122：“无法访问受保护的成员”，其实是误以为“同项目 = 能访问”，结果发现不是子类就报错 - 适用场景：框架基类中预留的钩子方法，比如
protected virtual void OnInitialized()，供下游继承者定制逻辑 - 注意：
protected字段或属性不能直接被子类的静态上下文访问（比如静态构造函数），必须通过实例或base调用
什么时候该用 internal？看程序集，不看继承
internal 是“项目内共享”的快捷键。只要在同一个编译产出（.exe 或 .dll）里，任何类——不管有没有继承关系、是不是嵌套类、甚至是不是 private 嵌套类的外层——都能直接访问 internal 成员。
2013年07月06日 V1.60 升级包更新方式：admin文件夹改成你后台目录名，然后补丁包里的所有文件覆盖进去。1.[新增]后台引导页加入非IE浏览器提示，后台部分功能在非IE浏览器下可能没法使用2.[改进]淘客商品管理 首页 列表页 内容页 的下拉项加入颜色来区别不同项3.[改进]后台新增/修改淘客商品，增加淘宝字样的图标和天猫字样图标改成天猫logo图标4.[改进]为统一名称，“分类”改
- 常见错误现象：把一个
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() { /* ... */ }
}
// ✅ 同一程序集，非子类 —— 可调用
class Helper
{
void Use() => new Base().Log();
}
// ✅ 不同程序集，但继承了 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，结果非子类调不了。关键不是记口诀，而是每次写访问修饰符前，先问自己一句：我到底在防谁？是怕别人继承，还是怕别人引用？
