最推荐用C++20的std::endian枚举，编译期确定字节序且无运行开销；次选union法兼容老标准；htons仅限POSIX环境；__BYTE_ORDER__宏适合GCC/Clang编译期分支。
用 std::endian 直接查（C++20 起最可靠）
如果你的编译器支持 C++20（如 GCC 12+、Clang 12+、MSVC 2019 16.11+），std::endian 是唯一标准、无副作用、零成本的方式。
它在 <type_traits></type_traits> 中定义，值为 std::endian::little、std::endian::big 或 std::endian::native（等价于前两者之一）。
常见错误是误以为 std::endian::native 可能是中间态——它永远等于 little 或 big，不会是其他值。
#include <type_traits>
#include <iostream>
<p>int main() {
if constexpr (std::endian::native == std::endian::little) {
std::cout << "little-endian\n";
} else {
std::cout << "big-endian\n";
}
}- 必须用
if constexpr：因为std::endian值在编译期确定，运行时比较会触发未定义行为 - 不要试图取地址或转型成
int：它的底层表示未指定，仅用于==编译期比较 - 不支持 C++17 及更早版本——此时该类型不存在，编译直接失败
用联合体（union）+ 指针别名检测（C++11~C++17 兼容方案）
当无法使用 C++20 时，最常用且被广泛验证的方法是定义一个 union，写入多字节整数后读取最低字节。这是 ISO C++ 标准允许的“活跃成员切换”行为（C++11 起明确合法）。
立即学习“C++免费学习笔记（深入）”；
关键点在于：不能用指针强制 reinterpret_cast 到 char* 后取索引——虽然多数编译器允许，但严格来说可能违反 strict aliasing 规则；而 union 是标准背书的替代方案。
constexpr bool is_little_endian() {
union { uint32_t i; uint8_t c[4]; } u{.i = 0x01020304};
return u.c[0] == 0x04;
}- 用
uint32_t（而非int）确保长度固定、无符号，避免符号扩展干扰 - 初始化用
{.i = ...}指定初始化器，避免旧式初始化在某些编译器下触发警告 - 返回
bool而非枚举：便于内联、条件编译，也符合多数网络/序列化库的判断习惯 - 不要用
int x = 1; char* p = (char*)&x;这种方式——GCC/Clang 在-O2下可能优化掉该判断
用掩码 + 移位判定（规避 union 的极简运行时方案）
某些嵌入式环境或受限编译器（如某些 ARM IAR 工具链）对 union 初始化支持不稳，此时可用纯算术方式：将 1 左移若干位，再右移回原位，观察是否“丢失高位”。
原理是：在小端机上，int 的 LSB 存于低地址，但移位操作本身与字节序无关；真正有效的是借助内存布局——所以这个方法其实仍是间接依赖存储表现，只是不显式用 union。
更稳妥的做法是用已知字节模式的数组，配合指针解引用：
bool is_little_endian() {
const uint16_t probe = 0x0001;
return *reinterpret_cast<const uint8_t*>(&probe) == 0x01;
}- 必须用
const uint8_t*解引用：避免对uint16_t对象做非对齐或越界访问 - 不能省略
const限定符：否则可能触发编译器对只读数据段的写保护检查 - 该函数不可
constexpr（因含运行时指针操作），若需编译期常量，请退回 union 方案 - 某些 hardened 编译选项（如
-fno-strict-aliasing）会影响此写法行为，务必测试目标平台
为什么不能只靠 __BYTE_ORDER__ 宏？
很多 C/C++ 项目会看到 __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ 这类预处理判断，但它不是标准 C++ 的一部分，而是 GCC/Clang/BSD libc 等实现提供的扩展宏。
问题在于：它反映的是**编译目标平台**的默认字节序，而非当前运行时系统的真实行为。例如交叉编译时，你用 x86_64 工具链编译 ARM 程序，__BYTE_ORDER__ 仍可能是 __ORDER_LITTLE_ENDIAN__（因为工具链宿主机是 x86），但目标 ARM 设备可能是大端（如旧款 PowerPC 兼容模式）。
- 仅适用于“编译平台 == 运行平台”的场景（如本地开发调试）
- 在容器、WASM、混合架构部署中极易出错
- Windows MSVC 完全不定义这些宏，代码直接失效
- 即便可用，也应作为 fallback，优先走
std::endian或运行时检测
实际工程中，字节序判断往往出现在序列化、网络收发、内存映射文件解析等环节。最易被忽略的是：同一进程里不同模块可能用不同方式判断，导致逻辑分支不一致——建议统一封装为一个头文件内联函数，并加 static_assert 校验结果与编译宏是否冲突。
