大端序高位字节存低地址、小端序低位字节存低地址；转换前必须确认字节流序与cpu序是否一致，x86/x64和多数arm为小端，网络字节序固定大端，混淆会导致数值解析错误。
什么是大端小端，为什么转换前得先确认平台字节序
直接用 ntohl 或 htons 之前，得先知道你读/写的字节流是按什么序存的，以及当前 CPU 是什么序。x86/x64 默认小端，ARM 多数也是小端（但可配），网络字节序固定是大端。混淆这两者，会导致数值解析完全错——比如把 0x01020304 当小端读成 66051，当大端读却是 16909060。
判断当前平台是否小端最稳妥的方式是用联合体或指针取最低地址字节：
bool is_little_endian() {
uint16_t x = 1;
return *(uint8_t*)&x == 1;
}
注意：别依赖 __BYTE_ORDER__ 宏，它在某些交叉编译环境（如 Android NDK）可能未定义或不准。
整数类型的手动字节序翻转（不依赖系统函数）
系统函数如 ntohl 只支持 uint32_t 和 uint16_t，且只处理网络↔主机转换；如果你要转换任意长度（如 uint64_t）、或做主机↔主机（比如小端机之间传数据但约定用大端序列化），就得自己翻字节。
- 对
uint32_t：((x & 0xFF) > 8) | ((x & 0xFF000000) >> 24) - 对
uint64_t：推荐用std::byteswap（C++23）或__builtin_bswap64（GCC/Clang），比手写移位更安全、能被编译器优化成单条指令 - 对数组或结构体：不能直接
memcpy后整体翻，必须按字段类型分别翻——比如 struct 里混了int32_t和int16_t，得各自调用对应位宽的翻转函数
使用系统函数时的常见陷阱
htonl/ntohl 看似简单，但实际踩坑多在“类型匹配”和“符号性”上：
- 它们只接受
uint32_t，传入int32_t会触发隐式转换，负数变成巨大正数（如-1→0xFFFFFFFF），再ntohl解出来还是0xFFFFFFFF，不是-1 -
htons处理uint16_t没问题，但若你用short，而它在某些平台是 16 位有符号，就可能出错 - Windows 上要用
winsock2.h，Linux/macOS 用arpa/inet.h；头文件没包含或顺序错（比如winsock2.h必须在windows.h前），链接会报undefined reference to `ntohl`
跨平台序列化建议：统一用大端 + 显式类型
如果你在写协议或文件格式（比如自定义二进制日志），别指望靠平台自动转换。最稳的做法是：
- 所有字段都按大端序列化，无论运行在哪种 CPU 上
- 用固定宽度类型：
uint8_t、uint32_t、uint64_t，避免int或long的平台差异 - 对每个字段，在序列化前调用翻转（如小端平台写入前用
std::byteswap），反序列化时再翻一次 - 别用
reinterpret_cast直接把 struct 地址 cast 成 char* 写——struct 可能有填充字节，且字段顺序受编译器影响
真正麻烦的从来不是翻字节本身，而是确保读写两端对“哪个字段该翻、翻几次、是否带符号”有一致理解。协议文档里哪怕只写一句“所有整数字段为大端无符号”，都能省掉后续三天 debug。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
