最轻量、最常用的方法是定义union{uint32_t value; uint8_t bytes[4];}，赋值0x01020304后检查bytes[0]：等于0x04为小端，等于0x01为大端，该方法符合c++标准且规避严格别名问题。
用联合体（union）快速检测字节序
最轻量、最常用的方法是定义一个 union，把整数和字节数组共享内存，再检查最低地址处的值。这是编译期无关、运行时即得结果的方式，且不依赖任何库。
常见错误是直接对指针做类型强转并解引用，比如 *((char*)&x)，这在严格别名规则（strict aliasing）下属于未定义行为；而 union 是标准允许的合法途径。
union {
uint32_t value;
uint8_t bytes[4];
} endian_test = {0x01020304};
bool is_little_endian = (endian_test.bytes[0] == 0x04);
-
bytes[0]对应最低地址字节：Little-Endian 下存的是最低有效字节（0x04），Big-Endian 下是最高有效字节（0x01） - 用
uint32_t而非int，避免符号扩展或宽度不确定问题 - 初始化值选
0x01020304是为了四个字节互异，便于调试时一眼识别顺序
用 std::endian（C++20）直接查标准枚举
C++20 引入了 std::endian 枚举，编译器在编译期就知道目标平台字节序，无需运行时判断。但注意：它反映的是**目标平台 ABI 的约定**，不是当前运行时环境（比如交叉编译时，它返回目标机的字节序，而非构建机的）。
常见误用是把它当成运行时探测手段——它根本不会生成运行时代码，所有比较都在编译期完成。
- 判断当前平台是否为小端：
std::endian::native == std::endian::little - 注意
std::endian::native不一定等于std::endian::big或std::endian::little（理论上存在 middle-endian，但现实中几乎不存在） - 若项目要求 C++17 及以下，该方案不可用，需回退到 union 或编译器宏
依赖编译器内置宏（如 __BYTE_ORDER__）的陷阱
GCC/Clang 提供 __BYTE_ORDER__ 宏，值为 __ORDER_LITTLE_ENDIAN__ 或 __ORDER_BIG_ENDIAN__，看起来很直接。但问题在于：它由编译器根据目标架构推断，**不随运行时环境变化**，且某些嵌入式工具链可能未定义。
更隐蔽的问题是，它无法反映运行时加载的动态库或 mmap 内存的实际布局（虽然极少遇到）。如果你写的是跨平台通用库，又想零运行时开销，这个宏可以作为 fallback，但务必加 #ifdef 保护。
- 必须先检查宏是否存在：
#ifdef __BYTE_ORDER__，否则在 MSVC 或旧编译器上直接报错 - MSVC 不支持该宏，需单独处理：
_M_IX86、_M_X64默认 Little-Endian，_M_ARM64同样是 Little-Endian（ARM64 没有硬件 Big-Endian 模式） - 不要混用：
__BYTE_ORDER__和__BIG_ENDIAN__（后者是旧宏，已废弃）
网络字节序转换函数不能用来判断本地序
有人试图用 htonl(1) 的结果反推本地序，这是危险的。因为 htonl 是确定性转换（总是转成 Big-Endian），其返回值只说明“输入是否等于输出”，不能覆盖所有情况——比如在 Big-Endian 机器上 htonl(1) == 1，但在某些特殊平台（如某些 PowerPC 模式）下，htonl 可能被优化为空操作，导致误判。
本质问题在于：htonl 是语义函数，不是探测接口。它不承诺暴露底层内存布局，也不在标准中定义其实现方式。
- 永远不要用
htonl/ntohl的返回值做字节序判断 - 如果已在用 POSIX 接口，优先信任
__BYTE_ORDER__或std::endian，而不是逆向工程网络函数 - 嵌入式裸机环境通常无
arpa/inet.h，这条路根本走不通
真正需要运行时检测的场景其实很少——绝大多数时候，你只需要知道编译目标平台的约定。union 方案简单可靠，std::endian 最干净，但三者适用条件差异很大。最容易被忽略的是：在共享内存、文件格式解析或网络协议实现中，你以为的“本地序”可能被 mmap 标志、CPU 运行模式或外设 DMA 打乱，这时候光靠一次检测并不够。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
