最稳妥的编译期方法是直接用 std::endian::native（C++20 起），但仅反映编译目标平台；运行时真实字节序必须用 union 检测，它是唯一标准、无副作用且兼容 C++11 的方案。
直接用 std::endian::native 是最稳妥的编译期方法，但运行时真实环境可能不匹配；真要查当前进程实际字节序，必须走运行时检测，union 是唯一既标准又无副作用的选择。
用 std::endian 编译期判断（C++20 起）
它不是“探测”，而是编译器根据目标平台 ABI 直接填入的常量，值在编译时就固定了。
-
std::endian::native恒等于std::endian::little或std::endian::big，不会是 runtime 未知值 - 必须包含
<bit>头文件，且编译器需支持 C++20（GCC 12+、Clang 13+、MSVC 19.30+） - 若项目需兼容旧工具链（如嵌入式 GCC 10），直接使用会报错：
'endian' is not a member of 'std' - 适用于模板特化或
if constexpr分支，但无法反映 QEMU 模拟、容器内核重映射等运行时异常场景
示例：
#include <bit> static_assert(std::endian::native == std::endian::little); // x86_64 上必然通过
用 union 做运行时检测（C++11 起通用）
这是唯一能拿到当前进程真实内存布局的方法，不依赖编译器假设，也不触发 strict aliasing 违规。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
- 必须用固定宽度整型（如
uint32_t），避免int在不同平台尺寸不一致 - 初始化推荐用指定成员语法：
u{.i = 0x01020304}，清晰且兼容 C++11 - 不能用
char*强转取地址 ——O2下编译器可能优化掉读取逻辑，行为未定义 - 测试值选
0x01020304是因为高低字节非对称，可明确区分u.c[0]是0x04（小端）还是0x01（大端）
示例：
bool is_little_endian() {
union { uint32_t i; uint8_t c[4]; } u{.i = 0x01020304};
return u.c[0] == 0x04;
}
别碰 __BYTE_ORDER__ 宏和指针强转法
它们看起来省事，但实际埋雷。
-
__BYTE_ORDER__是编译器根据构建主机或目标 ABI 设定的宏，交叉编译时完全不可信（比如 x86 工具链编译 ARM 程序，它仍报__ORDER_LITTLE_ENDIAN__） - 指针强转（如
(uint8_t*)&i）违反 strict aliasing 规则，-O2下可能生成错误代码，Clang 甚至会警告cast from 'uint32_t *' to 'uint8_t *' increases required alignment - POSIX 的
BYTE_ORDER同样是头文件里静态定义的，和运行时无关
真正关键的点在于：编译期判断快而干净，但只告诉你“你被编译成什么样”；运行时检测慢一点点，但告诉你“你现在实际跑成什么样”。如果你在写跨平台序列化库、网络协议解析器或固件加载器，后者才是唯一可信的依据。
