最推荐用C++20的std::endian编译期判断，需编译器支持且仅适用于目标平台ABI；兼容旧标准应选union运行时检测，安全可靠；位掩码无法检测字节序，因其操作值语义而非内存布局。
直接用 std::endian（C++20）最省心，但得确认编译器支持；若需兼容 C++11～C++17，union 法比指针强转更安全可靠；位掩码本身不能检测字节序，所有试图用 x & 0xFF 或移位判断的写法都是无效的。
用 std::endian 编译期判断（C++20 起）
它不是运行时函数，而是编译器填入的 constexpr 枚举值，零开销、无副作用、不触发未定义行为。
- 必须包含
#include，且编译器开启 C++20（GCC/Clang 加-std=c++20，MSVC 用/std:c++20） -
std::endian::native永远等于std::endian::little或std::endian::big，不会是其他值 - 只能用于
if constexpr，不能用于#ifdef或运行时if—— 否则比较结果未定义 - 旧版工具链（如 GCC 11、MSVC 2019 v16.10 之前）可能不支持，
__cpp_lib_endian宏可做预检：#if defined(__cpp_lib_endian) && __cpp_lib_endian >= 201907L
用 union 运行时检测（C++11 兼容）
这是目前最广泛验证、标准背书、规避严格别名问题的方案。核心是让 uint32_t 和 uint8_t[4] 共享内存，检查低地址字节是否为测试值的 LSB。
- 必须用固定宽度无符号类型：
uint32_t（非int），避免平台差异和符号扩展干扰 - 初始化要显式：用
{.i = 0x01020304}或先赋值再读，不能只声明不初始化 - 测试值必须非对称（如
0x01020304），否则u.c[0] == u.c[3]时无法区分大小端 - 主流编译器（GCC/Clang/MSVC）默认允许 union 成员别名访问；若项目禁用
-fno-strict-aliasing，此法仍合法，而指针强转可能被优化掉
为什么 reinterpret_cast 指针法容易出问题
看似简洁，但隐患密集：它依赖编译器对严格别名规则的宽容度，而非标准保证。
- 用
int x = 1; *(char*)&x == 1是常见写法，但int有符号、宽度不固定（嵌入式可能是 16 位），且负值时结果不可靠 - 即使改用
uint32_t，reinterpret_cast仍违反 C++ 标准——只有char*和unsigned char*被明确允许用于别名访问 - 开启
-O2且启用-fstrict-aliasing时，GCC/Clang 可能将该读取完全优化掉，导致返回值不可预测 - 若坚持用指针法，唯一合规写法是：
unsigned char* p = reinterpret_cast(&val); return p[0] == 0x04;
位掩码（&、>>）根本不能检测字节序
这是最常被误解的一点：位运算是值语义操作，与内存中字节的物理排列无关。
-
uint32_t x = 0x01020304; auto low = x & 0xFF;永远得0x04，无论小端还是大端——因为这是整数的逻辑低 8 位，不是地址 0 处的字节 - 试图用
(x >> 0) & 0xFF、(x >> 8) & 0xFF等模拟“按地址提取”，本质是在做字节序转换，不是检测 - 真正需要掩码的场景，是解析已知字节序的二进制协议（比如把网络字节流转成本地整数），此时你 already know the endianness
- 所有声称“用掩码判定字节序”的代码，要么隐含了 union / 指针访问，要么逻辑错误
真正容易被忽略的是：std::endian::native 描述的是目标平台 ABI 的约定字节序，不是当前进程实际运行时状态；而 union 和指针法检测的是当前 CPU 在当前模式下真实的内存布局。如果你在 ARM 上启用 BE8 模式或某些协处理器切换端序，只有运行时检测能反映出来——但这种情况极少见，绝大多数项目只需选对一种方法并保持一致。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
