protected成员专为继承预留，仅可在派生类成员函数内直接访问，类外（含派生类对象）不可访问；它不等同于“半公开”，也不受protected继承方式影响，是纯编译期检查的访问控制机制。
protected 成员不能被类外对象直接访问，但能在派生类内部自由使用——这是它最核心的用途，不是“半公开”，而是“专为继承预留”的访问层级。
为什么 protected 成员在派生类里能用，但在对象上调用就报错
关键在于访问位置：只要代码写在派生类的成员函数体内，protected 成员就合法；一旦写在 main() 或任意非派生类作用域，哪怕通过派生类对象调用，编译器立刻拒绝。
常见错误现象：error C2248: 'Base::m_protected_data': cannot access private member（注意：这个错误提示常误写为 private，实际是因访问位置非法触发的统一拒访机制）。
使用场景：你希望子类能复用、扩展基类逻辑（比如重写 calculate() 时读取 m_cache），但又不希望用户通过 obj.m_cache 破坏封装。
立即学习“C++免费学习笔记（深入）”；
- 基类中声明
protected成员，仅开放给继承链内部 - 派生类可直接读写该成员，无需额外 getter/setter
- 类外代码无法通过任何对象（包括派生类对象）访问它
protected 继承方式 vs protected 成员权限——别混为一谈
这是两个独立维度：protected 是成员访问修饰符；而 class D : protected B 中的 protected 是继承方式，控制基类成员在派生类中的“新权限”。
性能/兼容性影响：无运行时开销，纯编译期检查。但若滥用 protected 继承，会导致派生类对象无法隐式转为基类指针（破坏 is-a 关系），下游接口调用会直接编译失败。
-
class B { protected: int x; };→x只能在B及其派生类内部访问 -
class D : protected B { void f() { x = 1; } };→ 合法，D内部可访问x -
class D : protected B {};→ 此时B的 public 成员在D中变为protected，外部不可见
什么时候该用 protected 而不是 private 或 public
选 protected 的唯一合理动机：你明确预期这个成员会被子类依赖，且不希望它出现在类的公有接口中。
容易踩的坑：把本该 private 的数据（如内部缓冲区状态）设为 protected，等于向所有未来子类暴露实现细节，一旦修改就会引发连锁编译错误；反过来，把本该 protected 的计算中间量设成 private，子类只能重复实现或绕道 hack（比如加 friend 类），反而破坏设计清晰度。
- public：对外提供稳定契约，如
getArea() - protected：留给子类定制的钩子或共享状态，如
m_radius（当Circle和Sphere都需它） - private：纯内部实现，如
m_cached_area_valid
protected 成员在多重继承和模板中的行为一致性
它不因继承路径增多或模板实例化而改变规则：只要访问发生在某个派生类的成员函数内，且该类确实从声明了该 protected 成员的基类继承而来（直接或间接），就允许访问。
但要注意钻石继承下的二义性：如果两个父类都带同名 protected 成员，且未用 virtual 修饰，则派生类中直接写 member 会编译失败，必须加作用域限定，如 Parent1::member。
可给出简短示例：
class A { protected: int val = 42; };
class B : public A {};
class C : public A {};
class D : public B, public C {
public:
void f() {
// B::val = 1; // OK，显式指定
// C::val = 2; // OK
// val = 3; // error: ambiguous
}
};
真正复杂的地方在于：protected 不提供“受控降级”能力——你无法让某个特定子类看到它，而另一个看不到；它是继承树上的全局开关。一旦声明为 protected，所有直接/间接派生类都获得同等访问权，这点常被忽略。
