跨平台写入浮点数必须先用memcpy提取IEEE 754位模式为整数，再经htonl/ntohl等端序转换后写入；读取时严格逆向操作，否则在x86_64与ARM64等异构平台间将产生错误解析。
写入前必须显式转换为确定端序的整数类型
直接用 write() 写入 float 或 double 变量，会把内存原样 dump 出去 —— 这在 x86_64（小端）和 ARM64（可能大端或小端）之间完全不可移植。IEEE 754 本身不规定字节序，端序由硬件决定。
正确做法是先将浮点数按 IEEE 754 解释为整数位模式，再手动做端序转换：
- 用
std::memcpy(&uint32_t_val, &f, sizeof(float))提取位模式（禁止用 union 或 reinterpret_cast —— 未定义行为） - 调用
htons()/htonl()或手写翻转逻辑（std::byteswapC++23 起可用，但需检查编译器支持） - 再把转换后的
uint32_t按字节写入流
示例片段：
float f = 3.14159f; uint32_t bits; std::memcpy(&bits, &f, sizeof(float)); bits = htonl(bits); // 网络序（大端）作为标准 out.write(reinterpret_cast<const char*>(&bits), sizeof(bits));
读取时必须严格逆向操作，且不能依赖平台默认解释
如果写入用了网络序，读取时必须先读整数、再反转、再 memcpy 回 float —— 即使当前机器是小端，也不能跳过 ntohl()。否则在跨平台场景下，同一份文件在不同机器上会解析出完全错误的值（比如 1e-45 变成 NaN 或极大数）。
立即学习“C++免费学习笔记（深入）”；
常见错误包括：
- 读取后直接 reinterpret_cast 到 float：跳过了端序还原，结果错乱
- 用
std::bit_cast（C++20）但没处理端序：它只做位重解释，不翻转字节 - 假设目标平台和写入平台一致：CI 构建机、嵌入式设备、WASM 环境都可能不同
安全读取示例：
uint32_t bits; in.read(reinterpret_cast<char*>(&bits), sizeof(bits)); bits = ntohl(bits); float f; std::memcpy(&f, &bits, sizeof(float));
double 同理，但要用 uint64_t + htonll（需自行实现）
htonl() 和 ntohl() 只支持 32 位；htons() 是 16 位。对 double，必须用 uint64_t 并手动实现 64 位网络序转换：
- 没有标准库函数，可写一个 portable 的
htonll()（基于位移 + 掩码） - 避免依赖
__builtin_bswap64（GCC/Clang 特有，MSVC 不支持） - 注意：某些嵌入式平台 long long 可能非 64 位，务必用
uint64_t
简易 htonll 实现（无符号安全）：
uint64_t htonll(uint64_t value) {
static const int num = 42;
if (*(const char*)&num == 42) return ((uint64_t)htonl(value & 0xFFFFFFFF) << 32) | htonl(value >> 32);
return value;
}
（该判断检测小端；实际项目建议用 std::endian C++20 编译期判断）
别碰 std::ofstream::binary + locale / facet
试图用 imbue() 或自定义 std::codecvt 处理二进制浮点 —— 完全无效。这些设施只影响字符编码（如 UTF-8 转换），对 write() 的 raw 字节流零作用。启用 locale 后反而可能意外触发缓冲区截断或宽字符误判。
真正要做的只有三件事：
- 打开流时用
std::ios::binary - 所有浮点数走「位模式提取 → 端序转换 → 整数写入」流程
- 所有读取走「整数读入 → 端序还原 → 位模式还原」流程
任何想绕过这一步的“捷径”，最终都会在某次部署到异构环境时暴露。
最易被忽略的是：即使只在 x86_64 上开发测试，也要模拟大端读取验证逻辑 —— 比如用 QEMU 运行大端镜像，或在代码中临时强制反转字节再解析。否则上线后第一个跨架构用户就会遇到静默数据损坏。
