public继承STL容器几乎总是错误的，因其缺乏虚析构函数导致多态销毁未定义行为，引发对象切片、无法安全扩展接口，且违背值语义设计初衷；应优先采用组合+委托。
直接继承 std::vector、std::map 等 STL 容器不是语法错误，但绝大多数情况下属于设计误用——它破坏了封装性、引入切片风险、且无法安全参与多态，除非你明确在做类似 DuckDB 那样的底层增强。
为什么 public 继承 STL 容器几乎总是错的
STL 容器没有虚析构函数，也没有虚函数接口，它们不是为被继承而设计的。一旦你写 class MyVec : public std::vector<int></int>，就等于承诺“MyVec 是一种 std::vector<int></int>”，但标准库容器不支持多态销毁：如果有人用 std::vector<int>* p = new MyVec;</int>，再 delete p;，就会触发未定义行为（析构函数不 virtual，派生类部分不会被清理）。
更现实的问题是对象切片：把 MyVec 传给接受 std::vector<int></int> 的函数时，所有你加的成员和重载都会丢失；反过来，想通过基类指针调用你新增的方法，根本做不到——因为没虚函数，也没多态入口。
- STL 容器的接口是值语义导向的（copy/move），不是面向继承的接口设计
- 它们内部无 protected 成员或虚函数钩子，你无法“定制行为”，只能覆盖或隐藏（如重写
push_back），但这会破坏原有契约 - 继承后无法控制内存布局变化，某些调试模式（如 DuckDB 的
MemorySafety）需要显式重写所有访问路径，不是简单套一层就能生效
什么时候可以考虑继承（且必须谨慎）
仅当满足全部以下条件时，才值得考虑 public 继承 STL 容器：
立即学习“C++免费学习笔记（深入）”；
- 你完全掌控该类型的生命周期——绝不通过基类指针/引用创建或销毁对象
- 你明确要复用其所有接口，并在此基础上添加**非多态、非虚、不可被外部替换**的行为（例如带边界检查的
operator[]） - 你愿意承担所有访问函数（
at()、operator[]、data()、front()等）全部重写的成本，否则容易漏掉安全检查 - 你使用的是 C++17 或更新标准，并启用
[[no_unique_address]]等特性来避免空基类膨胀（若你继承的容器分配器是空类型）
典型可行场景：数据库系统（如 DuckDB）中定义 unsafe_vector 和 vector，二者都继承自 std::vector，但通过模板参数控制检查开关，且整个系统内绝不用 std::vector* 指向它们。
比继承更安全、更清晰的替代方案
99% 的业务需求，应该用组合 + 委托，而不是继承：
- 用
class MyContainer { std::vector<int> data_; };</int>封装，只暴露你需要的接口（size()、at()、push_back()），并可自由添加日志、验证、统计等逻辑 - 若需兼容 STL 接口，可提供
begin()/end()迭代器，或data()和size()，让算法能直接操作内部容器 - 若需零开销抽象，用 CRTP（
template<class derived> class ContainerBase</class>）替代运行时多态，避免虚函数和指针间接跳转 - 若只是想省代码，优先考虑
using别名（using IntVec = std::vector<int>;</int>）或函数式包装（template<typename t> auto safe_at(const std::vector<t>& v, size_t i) { ... }</t></typename>）
组合让你对“谁负责什么”一清二楚；继承 STL 容器则把责任模糊化——你既不是容器的设计者，也不是它的用户，而是夹在中间强行改写契约的人。
最容易被忽略的细节：移动语义与异常安全
如果你真决定继承，必须手动补全移动构造函数和移动赋值运算符——std::vector 虽然自己实现了移动，但派生类的默认版本只会按位复制你的新增成员，可能造成资源重复释放或悬空指针。
另外，所有你重写的函数（尤其是 operator[] 或 at()）必须严格保持异常规范一致：at() 抛 std::out_of_range，operator[] 不抛，你不能反着来，否则上层泛型算法（如 std::for_each）行为会失控。
最隐蔽的坑是分配器传播：若你模板化了容器类型并允许自定义分配器，继承时必须显式转发分配器参数到基类初始化列表，否则 std::vector<t a></t> 的构造可能用默认分配器，导致内存不一致。
