绝大多数情况下，私有继承不该用。它的语义是“用…来实现”，但读代码的人很容易误以为这是“是…的一种”关系，直接破坏了Liskov替换原则——子类对象没法安全地替代基类使用。标准库几乎不碰这个模式，std::stack、std::queue 这些容器适配器，清一色采用组合（private 成员 + using 声明接口），而不是私有继承。
私有继承在C++中到底该不该用
上面已经给了结论：绝大多数场景下，别碰。但总有些特殊需求，让组合显得无力——比如你想访问基类的 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 声明。但这里有几个反直觉的坑：
using Base::func;只能暴露public成员；对protected成员无效（它本来在派生类内部就能访问）。- 如果基类是模板类（比如
base），私有继承后，using base在某些旧编译器（GCC 7 之前）可能报错，需要改用::func; this->base显式调用。::func() - 友元关系不继承：基类的友元不能访问派生类的私有继承部分，除非你在派生类中重新声明友元。
- 模板参数推导失败的常见情形：把私有继承类的对象传给期望基类引用的函数时，编译器不会自动转换（因为不是“is-a”关系），你只能手动
static_cast——这本身就是一个危险信号。
真正棘手的地方往往不在语法，而在于团队协作。别人看到 : private Base 的第一反应是“这个类应该能当 Base 用”，然后花半天调试为什么 dynamic_cast 失败，或者虚函数没走重写版本。所以，除非你确实需要访问 protected 成员或重写虚函数且必须隐藏接口，否则，组合永远是更清晰的选择。
