htonl/ntohl不能直接用于Float，因其仅处理uint32_t字节翻转，强转违反严格别名且依赖ieee 754布局；安全做法是memcpy拆字节、反转、再memcpy回。
htonl 和 ntohl 为什么不能直接用在 float 上
因为 htonl 和 ntohl 只处理 32 位整数，底层是对 uint32_t 的字节翻转。把 float 强转成 uint32_t* 再传进去，看似能用，但实际依赖 IEEE 754 布局和平台对齐，且不保证符号/指数/尾数字段的翻转逻辑符合浮点语义——它只是“碰巧”在多数 x86/x64 上工作，但属于未定义行为。
真正安全的做法是：先用 memcpy 拆出原始字节，再逐字节反转，最后 memcpy 回去。这样不触发 strict aliasing，也和浮点格式解耦。
- 错误写法：
uint32_t i = *(uint32_t*)&f; i = htonl(i); f = *(float*)&i;—— GCC/Clang 在 -O2 下可能优化掉或报错 - 正确写法：用
std::memcpy中转，或 c++20 起可用std::bit_cast - 如果目标平台确定是 IEEE 754 且无 padding，可封装为 inline 函数，避免重复 memcpy 开销
判断主机序最靠谱的方式不是 __BYTE_ORDER 宏
__BYTE_ORDER 是 glibc 内部宏，不跨平台；MSVC 不认，Clang 在非 linux 下也不一定定义。更通用、标准的方法是运行时检测，靠联合体（union）或 char 数组取首字节。
例如声明一个 uint16_t 值为 0x0102，读其低地址字节：若为 0x01 就是大端，0x02 就是小端。这个方法不依赖编译器扩展，所有 C++11+ 环境都成立。
立即学习“C++免费学习笔记（深入）”；
- 别用
#ifdef __LITTLE_ENDIAN__—— 这些宏不是标准，不同工具链定义不一致 - 编译期判断可用
constexpr函数 + union，但注意 union 成员访问在 C++17 前有严格限制 - 网络库如 Boost.Endian 提供
is_little_endian，但引入依赖前先确认是否真需要
发送结构体前必须手动序列化，不能直接 send(Struct)
结构体直接 send 会把 padding 字节、指针地址、vtable 指针一起发出去，对方收到后几乎必然解析失败。尤其含 std::String、std::vector 或虚函数的类，绝对不可 memcpy。
正确路径是：定义明确的二进制布局（POD struct），确保 static_assert(std::is_standard_layout_v<t>)</t> 和 std::is_trivially_copyable_v<t></t> 都为 true，再用 reinterpret_cast<const char></const> 发送。
- 用
#pragma pack(1)或[[gnu::packed]]控制对齐，但要小心 CPU 对非对齐访问的性能惩罚甚至崩溃（ARMv7、RISC-V 可能异常） - 含字符串字段？必须拆成长度 + 数据两段，不能存
char[256]然后 memset 0 —— 接收方无法知道真实长度 - 跨语言通信（比如和 Python 解析）？优先用 Protocol Buffers 或 flatbuffers，手写序列化容易漏版本兼容性
ntohs/htons 处理 short 时要注意平台 int 类型宽度
ntohs 和 htons 专用于 16 位整数，参数类型是 uint16_t（或旧式 u_short）。但如果代码里写 htons((short)x)，而 short 在某些嵌入式平台是 32 位，就会截断或符号扩展出错。
始终显式使用固定宽度类型：传 static_cast<uint16_t>(x)</uint16_t>，而不是依赖 short 的大小。C++20 起还可考虑 std::byteswap，它模板推导类型宽度，更泛化。
- 错误示例：
htons(-1)——int转u_short会做模运算，-1 变成 65535，再翻转，结果不是你想要的“补码翻转” - 接收方用
ntohs后，若需 signed 运算，再转int16_t，别在翻转前后混用 signed/unsigned - 现代替代：C++23 的
std::byteswap支持float、double，但注意它不等价于网络序转换，只是字节翻转
字节序问题最麻烦的从来不是函数调用本身，而是混合了内存布局、编译器优化、跨平台假设之后，错误只在特定机器或特定编译选项下才暴露。宁可多写几行 memcpy，也不要赌“应该没问题”。