最稳妥方案是优先用C++20的std::endian::native（需启用标准并检查__cpp_lib_endian宏），不支持时fallback到union检测法，禁用预定义宏做运行时判断。
直接用 std::endian::native 是最稳妥的跨平台方案，但必须确认编译器支持 C++20 且启用了对应标准。不满足时，得 fallback 到运行时检测 —— 而不是依赖预定义宏。
std::endian（C++20）是唯一编译期零开销方案
它在头文件 std::endian::native 表示当前目标平台的真实运行时字节序（不是编译主机，也不是 ABI 声明）。
- 必须开启 C++20 标准（如 GCC/Clang 加
-std=c++20，MSVC 用/std:c++20） - 检查宏
__cpp_lib_endian是否 ≥ 201907L，否则该常量不可用 -
if constexpr分支可被完全剪除，无任何运行时成本 - 注意：它不能用于模板参数推导以外的 constexpr 上下文（比如作为函数返回值类型）
union 检测法仍是运行时首选
当 C++20 不可用时，union { uint32_t i; uint8_t c[4]; } 是最通用、最安全的运行时检测方式。
- 给
i赋值0x01020304，查c[0]：等于0x04→ 小端；等于0x01→ 大端 - 必须用
uint8_t，不用char，避免符号扩展干扰判断 - C++11 起标准明确允许访问 union 中最后写入的成员，GCC/Clang/MSVC 全部稳定支持
- 别在
constexpr函数里用它 —— 写入 union 成员不是字面量操作
reinterpret_cast 指针法更轻但有对齐风险
代码最短：uint32_t v = 0x01020304; bool is_le = (*reinterpret_cast
- 本质和 union 一样，只是绕过 union 封装
- 局部变量在主流平台（x86/x64/ARM64）通常自然对齐，实际几乎无问题
- 但在某些嵌入式 ARM 配置或启用严格对齐检查（
-mstrict-align）时，可能触发未定义行为 - 比起 union，它更难被编译器优化为常量（尤其在函数内联受限时）
别信 __BYTE_ORDER__ 这类宏做运行时判断
像 __BYTE_ORDER__、__LITTLE_ENDIAN__ 是编译器在预处理阶段根据目标 ABI 插入的，反映的是“你打算生成什么平台的代码”，不是“当前机器实际怎么存字节”。
- 交叉编译时（比如 x86 主机编译 ARM 固件），宏告诉你的是 ARM 的约定，但你的测试程序跑在 x86 上
- 即便宏值匹配，也不能替代实测 —— 硬件异常、hypervisor 模拟、某些 FPGA SoC 可能动态切换端序（极少见但存在）
- 它们只适合做
#if分支的 fallback 或文档注释，不能当作事实依据
真正跨平台的关键不在“选哪种方法”，而在于分层设计：优先用 std::endian，降级走 union，禁用宏硬编码；所有检测逻辑必须封装成内联函数或 constexpr 变量，避免重复判断，也别让它泄漏到序列化核心路径里 —— 字节序适配应尽量前置到数据视图层，而不是每次读写都重检。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
