最可靠方式是用union：union { uint32_t i; uint8_t b[4]; } u = { .i = 1 }; bool is_little_endian = (u.b[0] == 1);它轻量、无依赖、符合标准，避免strict aliasing问题，且运行时准确。
用 union 一次性读取多字节整数的最低字节
最直接可靠的方式是定义一个 union，把 uint32_t 和 uint8_t[4] 映射到同一块内存，然后检查低地址处的字节是否为数值的最低有效字节（LSB）。如果 u.b[0] == 1，说明小端；否则大端。
注意：必须用固定宽度类型（如 uint32_t），避免不同平台 int 大小不一致；数组索引 [0] 对应最低地址，这是 C++ 标准保证的。
union {
uint32_t i;
uint8_t b[4];
} u = { .i = 1 };
bool is_little_endian = (u.b[0] == 1);
- 不能用
int或long—— 它们在 Windows x64 和 Linux aarch64 上大小不同 - 初始化必须用指定初始化器（
.i = 1）或先赋值再读，避免未定义行为 - 某些嵌入式平台可能禁用
union别名访问（如开启-fstrict-aliasing时），但主流编译器（GCC/Clang/MSVC）默认允许
用位掩码提取最低有效字节更安全？不，它依赖已有字节序假设
有人尝试用 (val & 0xFF) 判断——这其实毫无意义。因为 & 是逻辑运算，结果只和数值有关，和内存布局无关。比如 0x00000001 & 0xFF 永远是 1，无论系统是大端还是小端。
位掩码本身不暴露字节序；它操作的是寄存器中的值，不是内存中的原始字节排列。想靠位运算“绕过” union，反而会掩盖真实问题。
立即学习“C++免费学习笔记（深入）”；
-
(x & 0xFF)得到的是数值的低 8 位，不是内存地址 0 处的字节 - 若你先把
uint32_t强转成uint8_t*再解引用（如*reinterpret_cast<uint8_t>(&x)</uint8_t>），那本质还是union思路，只是写法更易出错 - 别试图用移位+掩码“模拟”字节提取——那是在做字节序转换，不是检测
编译期检测：用 std::endian（C++20）但要注意兼容性
C++20 引入了 std::endian 枚举，可直接写 std::endian::native == std::endian::little。但它不是宏，无法用于 #if 条件编译，且 MSVC 2019 及更早版本、GCC 9 之前均不支持。
如果你需要在模板特化或 constexpr if 中分支，它比运行时 union 更干净；但若目标平台不确定是否支持 C++20，仍得 fallback 到 union 方案。
-
std::endian::native是constexpr，可用于if constexpr - 不能用在
#ifdef或预处理器判断中——它不是宏 - Clang 10+、GCC 10+、MSVC 2022 17.2+ 才完整支持；旧项目慎用
为什么不能只看 CPU 架构就断定字节序
x86/x64 几乎总是小端，ARMv7+/AArch64 默认小端，但 ARM 也支持大端模式（BE8/BE32），尤其在嵌入式或虚拟化场景下可能被启用。PowerPC、SPARC 等则历史上就有大端变种。仅靠 __x86_64__ 宏判断，会在少数生产环境中翻车。
-
__aarch64__不等于小端——启动参数或固件可强制切换 - 某些 FPGA SoC 或自定义 RISC-V 核心可能配置为大端
- 跨平台库（如音视频编解码、网络协议解析）必须实测，不能猜
真正可靠的检测永远基于内存布局本身，而不是文档或架构名。哪怕只差一个字节顺序，memcpy 出来的数据就会全错——这事关二进制兼容，不是理论问题。
