绝大多数情况下不该用；仅当需访问基类protected成员或重写虚函数且必须隐藏接口时才不可替代，标准库倾向组合而非私有继承。
私有继承在C++中到底该不该用
绝大多数情况下，不该用。私有继承语义上表达的是“用…来实现”，但这种关系极易被误读为“是…的一种”，且破坏了Liskov替换原则——子类对象无法安全替代基类使用。标准库中几乎不出现私有继承，std::stack、std::queue 等容器适配器明确采用组合（private 成员 + using 声明接口），而非私有继承。
什么场景下私有继承比组合更合适
仅当需要访问基类的 protected 成员或需要重写虚函数，但又不希望暴露基类的公有接口时，私有继承才具备不可替代性。组合无法访问 protected 成员；而公有/保护继承又会暴露接口或引入多态风险。
- 典型例子：定制一个仅用于内部调度的
std::thread封装类，需重写其内部调度策略（依赖基类protected钩子），但对外完全隐藏join()、detach()等原生接口 - 另一个场景：复用某个已有类的虚函数机制（如
std::basic_streambuf），但禁止用户直接调用其pubsetbuf()或snextc()等底层接口 - 注意：
final类不能被继承，此时私有继承直接失效，必须改用组合 + 委托
私有继承 vs 组合：接口控制与内存布局差异
私有继承让派生类对象在内存中包含基类子对象（与组合相同），但基类的 public 和 protected 成员在派生类作用域内成为 private（不可被外界访问，也不可被进一步派生类访问）。组合则完全由你控制哪些成员暴露、如何转发。
- 私有继承下，基类的构造函数不会自动继承（C++11起可用
using Base::Base引入，但仅限于构造函数签名完全匹配） - 组合中可自由选择是否将底层对象设为
const，私有继承无法做到这点 - 调试时，私有继承的基类子对象在GDB中仍可见，但名字为
Base（无成员名），组合则显示为命名成员变量，更直观 - 若基类有虚函数表，私有继承仍会生成虚表指针（哪怕你不调用虚函数），组合则完全规避——这是关键性能差异点
容易踩的坑：using声明、友元与模板推导
私有继承后，若想选择性暴露某些基类成员，必须显式用 using 声明。但这里有几个反直觉限制：
立即学习“C++免费学习笔记（深入）”；
-
using Base::func;只能暴露public成员；对protected成员无效（它本来就在派生类内部可访问） - 若基类是模板类（如
base<int></int>），私有继承后，using base<int>::func;</int>在某些旧编译器（GCC 7之前）可能报错，需改用this->base<int>::func()</int>显式调用 - 友元关系不继承：基类的友元不能访问派生类的私有继承部分，除非你在派生类中重新声明友元
- 模板参数推导失败常见：当你把私有继承类的对象传给期望基类引用的函数时，编译器不会自动转换（因为不是“is-a”），必须手动
static_cast<base>(*this)，这本身就是危险信号
真正棘手的地方往往不在语法，而在于团队协作时其他人看到 : private Base 的第一反应是“这个类应该能当 Base 用”——然后花半天调试为什么 dynamic_cast 失败或虚函数没走重写版本。
