空基类优化（ebo）是编译器在满足条件时复用空基类存储空间的优化，要求基类无非静态成员、无虚函数，且单继承下首个空基类才可能被优化；加虚函数会因vptr插入而失效。
空基类优化（EBO）在C++里怎么生效
它不是你写个空类就自动压缩内存的魔法，而是编译器在满足特定条件时，把空基类的存储空间“复用”进派生类对象里——前提是这个空基类不和派生类或其他基类产生offsetof冲突。
典型生效场景：继承一个只含类型定义、静态成员或纯虚函数的空基类（比如std::allocator的默认实现、自定义的empty_tag）。但只要基类有非静态数据成员，哪怕只有1字节，EBO就失效。
- 必须是真实空类：不含非静态数据成员，不含虚函数表指针（即不能有虚函数）
- 多重继承下，只有第一个空基类可能被优化；其他空基类仍可能占位（取决于ABI和编译器）
-
sizeof结果会暴露是否触发EBO：sizeof(derived)等于sizeof(non_empty_member)，说明成功
为什么加了虚函数就废掉EBO
因为虚函数强制编译器为该类插入虚表指针（vptr），哪怕类里啥都不定义。这个指针本身要占8字节（64位平台），且必须有唯一地址，无法和其他成员叠在一起。
常见误判：以为struct empty_base { virtual ~empty_base() = default; };还是空的——错，它已有vptr，sizeof(empty_base)通常是8，继承它就不可能EBO。
立即学习“C++免费学习笔记（深入）”；
- 检查方法：用
static_assert(std::is_empty_v<yourbase>)</yourbase>，返回false就说明不满足EBO前提 - 如果需要多态又想省空间，改用类型擦除或模板策略，而不是靠虚函数+空基类
g++/clang vs MSVC 在EBO上的行为差异
标准只要求“允许”EBO，不强制。主流编译器都支持，但多重继承下的布局策略不同——尤其当多个空基类存在时，MSVC更保守，可能给每个空基类留独立偏移，而g++/clang倾向合并。
这意味着：跨平台代码若依赖reinterpret_cast或offsetof计算空基类地址，很可能出错。别假设static_cast<emptybase>(&d)</emptybase>和&d地址相等——只在单继承且EBO生效时才成立。
- 用
__is_empty（GCC/Clang）或__is_empty_class（MSVC）做编译期检测，比硬编码偏移安全 - 避免对空基类取地址后做算术运算；如需唯一标识，用
typeid或模板参数推导
实际节省了多少内存？别高估它的作用
单次EBO最多省1字节对齐填充，常见是省掉1~7字节“补位”，不是砍掉几KB。它真正价值在于容器类（如std::vector）大量实例化时的累积效应，或者深度嵌套的模板元编程中抑制膨胀。
但别为了EBO强行拆分逻辑：把本该是成员的std::mutex改成继承，不仅破坏封装，还可能因EBO失效反而更大（因为std::mutex不是空类）。
- 优先用
[[no_unique_address]]（C++20）替代空基类模式，语义更清晰、控制更直接 - EBO不可移植到C；如果头文件要被C代码包含，空基类得加
extern "C"隔离，否则ABI崩
记住：EBO是编译器对布局的“善意优化”，不是语言保证的行为。它藏在sizeof背后，也藏在你没测过的ABI边界里。
