用union判断字节序是最直接的底层方式：将0x01020304写入uint32_t成员，读取bytes[0]，若为0x04则是小端，若为0x01则是大端；c++17起union类型双关合法且可constexpr化。
用 union 判断字节序是最直接的底层方式
核心思路是：把一个整数（比如 0x01020304）写入 int 成员，再通过 char 数组成员读取最低地址字节——若该字节是 0x04，说明低位字节在前，即小端；若是 0x01，则是大端。
union 的内存布局保证所有成员从同一地址开始，且不插入填充，因此可安全用于此类类型双关（type punning），C++17 起明确允许通过 union 访问非活跃成员（只要类型兼容），比指针强转更标准、更可移植。
union EndianChecker {
uint32_t value;
uint8_t bytes[4];
};
bool is_little_endian() {
EndianChecker u{0x01020304};
return u.bytes[0] == 0x04; // 小端：最低地址存最低有效字节
}
- 必须用
uint8_t和uint32_t等固定宽度类型，避免char有符号性干扰 - 初始化值选
0x01020304而非1，能清晰区分每个字节，便于调试和验证 - 不要用
sizeof(int)做判断依据——它可能是 2/4/8 字节，且不等于平台字节序定义依据
编译期检测：用 constexpr + union 实现静态判断
运行时检测不够高效？C++20 起可将上述逻辑写成 constexpr 函数，在编译期确定字节序，适用于模板特化或 if constexpr 分支。
注意：union 在 constexpr 上下文中需满足 trivially copyable 且不含非 constexpr 构造函数；上面的 EndianChecker 满足条件。
立即学习“C++免费学习笔记（深入）”；
constexpr bool is_little_endian_constexpr() {
union { uint32_t v; uint8_t b[4]; } u{0x01020304};
return u.b[0] == 0x04;
}
static_assert(is_little_endian_constexpr(), "expected little-endian");
- C++17 已支持 constexpr union（只要成员是字面量类型），但部分老编译器（如 GCC 7 之前）可能不完全支持
- 避免在 constexpr 函数中使用
reinterpret_cast或指针解引用——它们不是字面量操作，会破坏 constexpr 性 - 某些嵌入式平台（如 ARM Cortex-M3）默认大端，但编译器可能生成小端指令流，务必以实际运行环境为准，不能只信文档
为什么不用 ntohl() 或 htons() 反推字节序
这些函数是网络字节序（大端）与主机字节序之间的转换工具，本身不暴露主机序信息。有人试图靠「调用 ntohl(1) 是否等于 1」来判断，这是错的：
-
ntohl()行为依赖当前主机序——小端机上返回0x01000000，大端机上才返回1，但你无法预先知道它返回什么来反推 - 它本质是条件翻转，不是探测接口；过度依赖会掩盖真实字节序逻辑，增加维护成本
- POSIX 不保证
ntohl在主机已是大端时是否真的做空操作——有些实现仍会走一遍位运算，不可靠
跨平台兼容性陷阱：ARM、PowerPC、RISC-V 的实际表现
现代 CPU 往往支持大小端切换（如 ARMv8 的 SETEND 指令、PowerPC 的 lwbrx），但操作系统启动后通常锁定一种模式。Linux 内核在启动时根据硬件能力选择并固化字节序，用户态程序看到的始终一致。
- RISC-V 目前主流实现（如 QEMU + Debian riscv64）默认小端，但规范允许大端，不能硬编码假设
- Windows on ARM（ARM64）强制小端；macOS on Apple Silicon 同样小端；但裸机固件（如 U-Boot）可能运行在大端模式
- 最稳妥做法：每次需要字节序敏感操作（如解析二进制协议、内存映射硬件寄存器）时，都显式检测或通过构建系统传入
-DHOST_LITTLE_ENDIAN宏
真正容易被忽略的是：union 方法在严格别名规则（strict aliasing）下是合规的，而用 char* 指针强转 int* 读取则可能被编译器优化掉——哪怕加了 volatile，也不如 union 语义清晰、行为确定。
