最推荐用 C++20 的 std::endian 枚举，编译期确定字节序且无运行开销；次选 union 法兼容老标准；htons 仅限 POSIX 环境；__BYTE_ORDER__ 宏适合 GCC/Clang 编译期分支。
用 std::endian 直接查（C++20 起）
这是最干净、最标准的方式，编译器自己知道答案，不依赖运行时猜测。std::endian 是个枚举，值为 std::endian::little、std::endian::big 或 std::endian::native。
常见错误现象：在 C++17 或更早项目里直接用，报错 ‘endian’ is not a member of ‘std’ —— 因为它只在 C++20 引入。
- 必须开启 C++20 支持（如 GCC/Clang 加
-std=c++20，MSVC 用/std:c++20） -
std::endian::native就是当前平台的字节序，不用再和little/big比较 - 它在编译期可求值，可用于
if constexpr分支，无运行时开销
示例：
if constexpr (std::endian::native == std::endian::little) {
// 小端逻辑
} else {
// 大端逻辑
}
用联合体（union）+ char 数组取首字节（兼容老标准）
这是 C++11/14/17 最常用且可靠的手法，原理是让整数和字节数组共享内存，看低地址存的是高位还是低位字节。
立即学习“C++免费学习笔记（深入）”；
容易踩的坑：union 成员读写顺序依赖活跃成员（active member），但只要只写一次、读一次且类型尺寸一致，就符合标准（C++11 起允许这种“类型双关”用于字符类型）。
- 务必用
uint32_t或固定宽度整型，避免int在不同平台尺寸不同 - 不能用
char*强转取地址 —— 可能触发严格别名违规（strict aliasing violation） - 测试时建议用十六进制字面量（如
0x01020304），方便肉眼核对字节顺序
示例：
bool is_little_endian() {
union { uint32_t i; uint8_t c[4]; } u{0x01020304};
return u.c[0] == 0x04; // 小端：最低位字节在低地址
}
用 htons() / ntohs() 判断（POSIX 环境下可行）
这类网络字节序函数本质是“大端转主机”或“主机转大端”，如果调用前后值不变，说明主机就是大端；否则是小端。
使用场景有限：仅适用于有 <>arpa/inet.h> 的系统（Linux/macOS/WSL），Windows 需要 <>winsock2.h> 且先调 WSAStartup，嵌入式裸机环境通常不可用。
- 输入值必须是非对称的（如
0x0001），避免0x0000或0xFFFF导致误判 - 返回值是
uint16_t，需显式比较原始值，不能只看是否为 0 - 性能无关紧要，但它是纯函数、无副作用，适合做 compile-time 判断的 fallback
示例：
#include <arpa/inet.h>
bool is_big_endian() {
return htons(0x0001) == 0x0001;
}
宏定义 __BYTE_ORDER__（GCC/Clang 编译期判断）
这是编译器提供的预定义宏，不运行代码就能知道字节序，适合做条件编译分支，比如选择不同 SIMD 指令或结构体布局。
为什么这样做：比运行时检测快，且能彻底剔除不用的代码路径，减小二进制体积。但注意——它不是标准 C++，MSVC 不支持，仅限 GCC/Clang。
- 值为
__ORDER_LITTLE_ENDIAN__或__ORDER_BIG_ENDIAN__，直接比较即可 - 别用
__BIG_ENDIAN__这类旧宏，它们行为不一致，有些平台未定义 - 不能用于跨平台头文件中无保护地使用，否则在 MSVC 下编译失败
示例：
#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
// 小端专用优化
#elif __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
// 大端专用优化
#endif
真正麻烦的不是判断本身，而是后续怎么用这个结果——比如你写了 if (is_little_endian())，但编译器根本没法把这当常量去优化掉。这时候就得回头选 std::endian 或宏方案，否则可能白忙活。
