写入二进制文件前必须将float/double通过std::memcpy转为整数，再用htonl/ntohl转换字节序，读写顺序严格逆向，且需静态断言大小匹配、文件头标识端序，以确保跨平台正确性。
写入二进制文件前必须手动处理 float / double 的字节序
浮点数在内存中按 IEEE-754 存储，但 C++ 标准不规定其字节序 —— 它完全跟随平台的整数端序（std::endian::native）。这意味着：你在 x86_64（小端）机器上直接 write() 一个 float，读取端若为 ARM 大端或网络字节序设备，就会解出完全错误的值。
不能依赖 htonl() 或 htons()：它们只针对整数类型，对浮点数调用是未定义行为，编译器可能静默接受但运行时崩或出错。
- 正确做法是把浮点数 reinterpret_cast 成对应长度的整数，再做端序转换
- 例如
float→uint32_t，double→uint64_t - 转换后用
htonl()/htons()或手写翻转逻辑，再写入文件
std::memcpy 比 reinterpret_cast 更安全地跨类型取位
直接 reinterpret_cast<uint32_t>(f)</uint32_t> 在严格别名规则下属于未定义行为（UB），尤其开启 -O2 后可能被编译器优化掉或乱序。实际项目中应优先用 std::memcpy 中转：
float f = 3.14159f; uint32_t u; std::memcpy(&u, &f, sizeof(f)); u = htonl(u); // 转网络字节序（大端） out.write(reinterpret_cast<const char*>(&u), sizeof(u));
注意：sizeof(float) == sizeof(uint32_t) 必须成立，否则 memcpy 会越界 —— 建议加静态断言：
立即学习“C++免费学习笔记（深入）”；
static_assert(sizeof(float) == sizeof(uint32_t), "float must be 32-bit");- 同理检查
double和uint64_t - 别假设
long double可以同样处理 —— 它在不同平台长度和布局差异极大，尽量避免写入
读取时顺序必须严格逆向：先读整数、再翻转、最后 memcpy 回浮点
写入是“float → uint → 翻转 → 写”，读取就必须反着来：否则哪怕字节没丢，语义也全错。常见错误是读完直接 reinterpret_cast<float>(u)</float>，忘了翻转回去。
- 读出的是大端整数？先用
ntohl()转回本地序 - 再用
std::memcpy拷贝到float变量，不可跳过这步 - 如果读取端是嵌入式小端设备，而文件存的是大端，则
ntohl()不可省；若文件本身就是小端（如只在 x86 内部传），那反而不该翻转 - 建议在文件头写 magic + 字节序标识（如
0x12345678表示大端），避免硬编码假设
IEEE-754 特殊值（NaN/Inf）在端序转换下依然有效
端序转换只翻转字节排列，不改变位模式含义。所以 NaN、+Inf、-Inf、-0.0 这些 IEEE-754 定义的特殊值，只要字节完整写入并正确翻转，读取后仍是合法的对应值。
但要注意：
- 某些旧平台或交叉编译工具链对
NaN的 payload 位处理不一致，建议用std::isnan()而非位比较验证 - 不要用
==判断读出的 float 是否等于写入值 ——NaN != NaN，该用std::bit_cast（C++20）或 memcpy 比较原始字节 - 如果文件需被 Python/Java 等语言读取，确保它们用相同字节序解析 —— Python 的
struct.unpack('>f', ...)是大端，'<f'是小端
端序不是玄学，是字节流里每个 bit 的位置问题。写错一个字节，3.14 就可能变成 1.7e-38 或 NaN，而且毫无报错提示。
