union 中只能安全存放平凡可复制且无非平凡析构函数的类型，如 int、float；std::string 等需构造/析构的类型直接使用会导致未定义行为。
union 里放什么类型才安全
union 的本质是同一块内存被多个类型轮流解释，所以只有“平凡可复制”（trivially copyable）且不带非平凡析构函数的类型才能放心塞进去。比如 int、float、uintptr_t 没问题；但 std::string、std::vector 或任何带构造/析构逻辑的类——直接用就是未定义行为。
常见错误现象：union { std::string s; int i; } u; 编译可能通过（取决于编译器警告级别），但一旦给 u.s 赋值后又读 u.i，或对象生命周期结束时没手动调用 s.~string()，程序大概率崩溃或静默出错。
- 使用场景：硬件寄存器映射、协议解析（如网络包头字段复用）、需要按不同整数宽度访问同一内存块
- 安全替代方案：C++17 起优先考虑
std::variant，它自带类型标记和自动析构，只是多几个字节开销 - 如果真要手写 union，必须配一个外部 tag 字段 + 手动管理生命周期（构造/析构需显式调用）
怎么避免 union 成员覆盖导致的读取错乱
union 不会自动记录当前激活的是哪个成员，读错成员就等于用错误的类型解释同一串比特。这不是 bug，是设计如此——你得自己负责“当前存的是谁、现在想读谁”。
典型错误现象：写入 u.f = 3.14f，紧接着读 u.i 得到一个看似随机的整数，还误以为是数据损坏；其实只是 IEEE 754 单精度浮点的内存布局被当成了整数解读。
立即学习“C++免费学习笔记（深入）”；
- 必须配套维护一个枚举或布尔标志，例如
enum class active_type { INT, FLOAT }; - 所有读写操作前检查/更新该标志，否则极易在多人协作或后期修改时漏掉同步
- 编译器不会帮你做运行时检查，
-fsanitize=undefined可捕获部分越界读，但对 union 类型误读无效
union 和 struct 的内存对齐差异怎么影响紧凑性
union 的大小等于其最大成员的对齐后尺寸，而 struct 是所有成员对齐要求的最大值之和（还要考虑填充）。想省空间，union 天然比 struct 更紧凑，但前提是成员对齐方式别拉胯。
例如：union { char c; double d; } 大小是 sizeof(double)（通常 8），因为 double 要求 8 字节对齐；但如果加一个 __m256 成员，整个 union 就会变成 32 字节对齐，哪怕你只存一个 char。
- 用
alignas可强制降低对齐，比如alignas(1) union { char c; double d; }让大小变成 8，但可能触发性能惩罚（非对齐访存） - 用
offsetof验证实际偏移，别信直觉：“第一个成员总在 offset 0”是对的，但“第二个成员紧挨着”在 union 里不成立——所有成员起始偏移都是 0 - 结构体嵌套 union 时，注意外层 struct 的对齐会被 union 拉高，可能抵消节省的空间
为什么 C++20 的 std::bit_cast 有时比 union 更合适
过去常用 union 实现类型双关（type punning），比如把 float 当作 uint32_t 看——但这在严格别名规则下属于未定义行为（C++ 标准不保）。C++20 引入 std::bit_cast，专为这种“按位重解释”设计，语义清晰且编译器能优化。
错误做法：union { float f; uint32_t u; } u; u.f = 3.14f; return u.u; —— GCC/Clang 在 -O2 下可能优化掉，结果不可靠。
- 正确替代：
return std::bit_cast<uint32_t>(3.14f);</uint32_t>，要求源目标大小一致且 trivially copyable - 兼容性：MSVC 19.29+、GCC 11+、Clang 12+ 支持；旧编译器只能退回到 memcpy（标准允许的合法 type punning）
- union 仍有不可替代场景：运行时动态决定解释方式（比如解析未知类型的二进制流），这时
std::bit_cast编译期就定死了
真正难的不是写 union，而是确保每次访问前都准确知道哪条路径是活的——这没法靠语法检查，全靠人盯住状态流转。稍一松懈，bug 就藏在字节深处，等压测时突然冒出来。
