用 union 检测字节序最可靠：union { uint32_t i; uint8_t c[4]; } u = { .i = 0x01020304 }; bool is_little_endian = (u.c[0] == 0x04)；它轻量、无依赖、符合标准，避免 strict aliasing 问题，且运行时准确。
用 union 读取多字节整数的首字节最直接
运行时判断字节序，本质是看一个 int（比如 0x01020304）在内存里最低地址处存的是高位还是低位。用 union 是最轻量、无依赖、不触发未定义行为的方式。
常见错误是用指针强转 int* 到 char* 后取 [0] —— 这看似简洁，但严格来说可能违反 strict aliasing 规则（尤其开 -O2 后编译器可能优化掉）。union 是标准允许的合法途径。
union { uint32_t i; uint8_t c[4]; } u = { .i = 0x01020304 };
bool is_little_endian = (u.c[0] == 0x04);
-
u.c[0]是内存起始地址的字节，小端下为0x04，大端下为0x01 - 必须用
uint32_t等固定宽度类型，避免int在不同平台宽度不同 - 初始化用指定成员（
.i = ...）更清晰，也兼容 C++11 及以上
用 std::endian（C++20）最干净，但要注意支持度
C++20 引入了 std::endian 枚举，编译期常量，写法极简：
#include <type_traits> constexpr bool is_little_endian = (std::endian::native == std::endian::little);
但它只在编译期有效，无法用于运行时动态检测（比如跨平台共享库中需适配宿主 CPU）。更重要的是：GCC 12+、Clang 13+、MSVC 19.30+ 才完整支持；旧版本或嵌入式工具链可能根本没定义 std::endian，直接编译失败。
立即学习“C++免费学习笔记（深入）”；
- 检查是否可用：
#ifdef __cpp_lib_endian或尝试包含<type_traits></type_traits>后查std::endian - 若项目需兼容 C++17 或更低，别用它，老老实实走
union路线 - 即使支持，
std::endian::native也不代表运行时实际环境 —— 比如在 QEMU 用户态模拟下，它仍返回宿主 CPU 的字节序，而非模拟目标
别信 __BYTE_ORDER__ 宏，它不可靠
很多 C/C++ 项目会看到 __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ 这类预处理判断，但它只是编译器根据目标平台默认设定的宏，不是运行时真实值。
典型坑出现在：交叉编译时，你用 x86_64 工具链编译一个给 ARM 运行的程序，__BYTE_ORDER__ 可能仍是 __ORDER_LITTLE_ENDIAN__（因为工具链本身跑在 x86 上），但 ARM 实际可能是大端（如旧版 ARMv7 的 BE8 模式）或可配置的（如 ARM64 的 SETEND 指令，虽已废弃但内核/固件层仍可能干预）。
-
__BYTE_ORDER__属于编译期假设，和最终运行环境无关 - 除非你 100% 确认部署环境与构建环境一致，且无运行时重配置机制，否则不能用于关键逻辑
- POSIX 的
BYTE_ORDER同理，它来自<endian.h></endian.h>，也是编译时头文件决定的
网络字节序转换函数不等于运行时检测
有人试图用 htonl(1) == 1 来判断：如果成立就是大端，否则小端。这很危险 —— htonl 是 libc 提供的函数，其行为依赖实现，某些嵌入式 libc 可能直接内联为恒等操作（假设平台永远是小端），或依赖编译器内置函数（__builtin_bswap32）间接推断，结果不可靠。
更严重的是：htonl 的语义是“转成网络字节序（大端）”，不是“检测本机序”。它可能被优化、被弱符号替换、甚至在 freestanding 环境下不存在。
- 不要把协议转换函数当检测手段，职责混淆
- 需要检测时，就用
union—— 它只依赖内存布局和基本类型，连标准库都不需要 - 如果已在用
htons/ntohl，说明你已有 libc 依赖，此时用union依然更可控
真正难的不是写对那几行代码，而是想清楚：这个检测发生在程序启动时？热插拔设备枚举时？还是跨进程共享内存映射后？不同场景下，“本机字节序”可能根本不是单一值 —— 比如某些异构计算卡通过 PCIe 映射的内存区域，CPU 和 GPU 对同一块地址的解读可能不同。
