union通过共享内存读写不同成员检测字节序：写入0x01020304后查bytes[0]值，0x01为大端、0x04为小端；但需确保uint32_t为4字节且无填充，并注意对齐与严格别名规则。
union 判定字节序的原理和可靠边界
union 的成员共享同一块内存，读写不同类型的成员能暴露底层字节布局。用 uint32_t 和 uint8_t[4] 构成 union，写入 0x01020304 后检查 bytes[0] 是 0x01 还是 0x04，就能判断大端还是小端。
但要注意：该方法仅对 uint32_t 大小为 4 字节且无填充的平台成立；在某些嵌入式平台或非标准 ABI 下，sizeof(uint32_t) 可能不是 4，或 union 对齐行为异常。建议先静态断言：static_assert(sizeof(uint32_t) == 4, "uint32_t must be 4 bytes");
用 constexpr union 实现编译期字节序检测
C++20 起，带 trivial 类型的 union 可用于 constexpr 上下文。下面这个结构体能在编译期返回 std::endian 值（C++20）或自定义枚举：
std::endian 值（C++20）或自定义枚举：
关键点在于所有操作必须是字面量类型、无副作用、不依赖运行时地址：
- 不能用
reinterpret_cast或指针解引用 - union 必须只含 POD 成员（如
uint32_t和std::array<uint8_t></uint8_t>） - 初始化需用 brace-init，且值必须是常量表达式
constexpr auto detect_endian() {
union { uint32_t w; std::array<uint8_t, 4> b; } u{.w = 0x01020304};
return (u.b[0] == 0x01) ? std::endian::big : std::endian::little;
}
union 字节序适配的实际封装技巧
直接裸写 union 容易出错，建议封装为工具类，隐藏 union 细节，暴露语义化接口：
- 对输入
uint16_t / uint32_t / uint64_t，提供 to_host() 和 to_network() 成员函数
- 内部用
if constexpr (std::endian::native == std::endian::big) 分支，避免运行时分支预测开销
- 禁止拷贝构造 union 成员，改用
memcpy 或 std::bit_cast（C++20）保证严格别名安全
uint16_t / uint32_t / uint64_t，提供 to_host() 和 to_network() 成员函数if constexpr (std::endian::native == std::endian::big) 分支，避免运行时分支预测开销memcpy 或 std::bit_cast（C++20）保证严格别名安全例如网络包解析中常见场景：
struct Header {
uint16_t len;
uint32_t seq;
// …
uint16_t to_host_len() const { return ntohs(len); } // 更推荐用标准函数
// 或：return byte_swap_if_be(len);
};
容易被忽略的陷阱：union + 未定义行为 + 对齐
最常踩的坑不是逻辑错，而是违反严格别名规则或对齐要求：
- 对 union 写入
uint32_t后，立即读uint8_t[4]是合法的（C++标准明确允许）；但反过来——写uint8_t[4]后读uint32_t——在非 4 字节对齐地址上可能触发 UB - 某些 ARM 编译器（如 armclang）对未对齐访问默认禁用，会静默截断或崩溃
- union 变量本身若未显式对齐（如
alignas(4)），在栈上分配时可能不满足uint32_t的对齐需求
所以实战中更稳妥的做法是：用 std::bit_cast（C++20）替代 union，或坚持用 ntohl/htons 等标准函数——它们由系统库保证正确性，且现代编译器能内联优化成单条指令。
立即学习“C++免费学习笔记（深入）”；
