运行时可通过union或std::bit_cast检测字节序：赋值0x01020304后查首字节，0x04为小端、0x01为大端；union法兼容C++11且无UB，std::bit_cast更类型安全但需C++20支持。
直接用联合体（union）或 std::bit_cast（C++20）读取多字节整数的首字节，就能可靠判断当前机器是小端还是大端——不用查文档、不依赖编译器宏，运行时一试便知。
用 union 读取 uint32_t 的最低地址字节最稳妥
这是兼容 C++11 及以上、零开销、无 UB 的经典做法。核心思路：把一个已知值（如 0x01020304）写入 uint32_t 成员，再通过 uint8_t[4] 数组成员读它在内存中的布局。
常见错误现象：有人用指针强制转换（如 (uint8_t*)&val）并假设索引 0 是 LSB，但严格来说，这依赖于对齐和对象表示，而 union 是标准明确允许“重叠访问”的合法途径。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 定义
union { uint32_t i; uint8_t c[4]; } u;，赋值u.i = 0x01020304; - 检查
u.c[0]：若等于0x04→ 小端；若等于0x01→ 大端 - 避免用
char*指针 +reinterpret_cast去读，某些静态分析工具会报可疑别名警告 - 该方法在所有主流平台（x86/x64/ARM64/RISC-V）上行为一致，无需额外条件编译
用 std::bit_cast（C++20）更现代但要注意对齐
如果你确定用的是 C++20 且目标平台支持，std::bit_cast 是类型安全的替代方案，它显式表达“按位重解释”，语义比 union 更清晰。
使用场景：适合写库函数或需要强类型约束的场合，比如封装成 constexpr 工具函数。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 写法示例：
auto bytes = std::bit_cast<:array>>(0x01020304_u32);</:array>，然后查bytes[0] - 必须确保源和目标类型满足
std::is_trivially_copyable_v且大小相等，否则编译失败 - 注意：
std::bit_cast要求对齐匹配，std::array<uint8_t></uint8_t>对齐为 1，而uint32_t通常对齐为 4 —— 实际中多数编译器能优化掉问题，但极少数嵌入式平台可能触发未定义行为 - 不能用于
constexpr上下文判断运行时字节序（因为字节序本身不是编译时常量），只能用于编译期已知架构的元编程
别信 __BYTE_ORDER__ 宏，它反映的是编译目标而非运行环境
很多开发者看到 __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ 就以为万事大吉，结果交叉编译到 ARM big-endian 设备上跑崩了——因为这个宏由编译器根据 -march 或 ABI 预设展开，跟实际 CPU 无关。
性能与兼容性影响：
- 宏判断是编译期常量，看似快，但一旦跨架构部署就失效；运行时检测虽多一次内存访问，但绝对可靠
- 某些 SoC（如部分 TI DSP 或旧 PowerPC）支持运行时切换字节序模式（via MSR），此时只有运行时检测才能反映真实状态
- Windows on ARM64 默认是小端，但固件层仍可能暴露大端外设寄存器，此时你真正要检测的可能是某块 MMIO 区域的解释方式，而非 CPU 主字节序
真正容易被忽略的一点：字节序检测本身不难，难的是后续逻辑是否真的按检测结果分支处理。比如只在小端路径里用了 ntohl()，却忘了大端路径需要反向操作——检测只是起点，别让它变成假安全感的源头。
