必须手动处理端序，std::ofstream::write 直接写浮点内存字节导致跨平台读取失败；应先用 std::bit_cast 或 memcpy 转为整数视图，再用 std::byteswap 统一端序后写入，读取时逆向操作并校验 IEEE 754 实现一致性。
写入前必须手动处理端序，std::ofstream 不会帮你转
二进制写入浮点数时，std::ofstream::write 只是原样 dump 内存字节——它不管你是 x86 小端还是 ARM 大端，也不管 IEEE 754 的符号/指数/尾数布局。跨平台读取失败，90% 是因为直接 write(&f, sizeof(f)) 后在另一端直接 reinterpret_cast 读，结果指数位错位、值全乱。
- 所有 IEEE 754 浮点类型（
float、double、long double）都需先转成确定端序的整数视图再写 - 推荐用
std::bit_cast（C++20）或memcpy转成对应宽度的整数类型：uint32_t对应float，uint64_t对应double - 再对这个整数做端序转换（如用
htobe32/htobe64，或手写翻转逻辑），最后 write 整数内存
htobe32 和 htole32 不是标准 C++，得自己兜底
Linux 有 endian.h，macOS 有 libkern/OSByteOrder.h，Windows 没这玩意儿。直接调用会编译失败或链接报错。
- 别依赖系统头，用 C++20 的
std::byteswap最稳（支持uint32_t/uint64_t） - 若不能用 C++20，手写翻转函数更可靠：
uint32_t swap32(uint32_t x) { return (x > 8) & 0x0000ff00) | (x >> 24); } - 注意：只对整数视图翻转，不是对 float 变量本身 cast 后翻——顺序错了就彻底破坏 IEEE 754 结构
读取时必须严格逆向操作，且要检查平台端序
写入用了大端，读取时不能假设当前机器也是大端。否则 std::bit_cast<float>(be64toh(u64_val))</float> 在小端机上会多翻一次，结果错误。
- 读取后先用
std::endian::native == std::endian::big判断本机端序（C++20） - 如果写入约定为大端，而本机是小端，则必须用
std::byteswap或le64toh等反向转换 - 别用
reinterpret_cast<float></float>直接强转——UB 风险高，且绕过 strict aliasing 检查，Clang/GCC 可能优化出错 - 示例安全读法：
uint64_t u64; is.read(reinterpret_cast<char*>(&u64), sizeof(u64));<br>if constexpr (std::endian::native == std::endian::little) u64 = std::byteswap(u64);<br>double d = std::bit_cast<double>(u64);
std::numeric_limits<float>::is_iec559 不等于“可用”，得实测
虽然大多数平台返回 true，但某些嵌入式编译器（如 IAR、Keil ARMCC）或老版本 GCC 可能禁用 IEEE 754 模式，或用非标准 padding。此时 sizeof(float) 还是 4，但内存布局不兼容。
立即学习“C++免费学习笔记（深入）”；
- 运行期加校验：写入一个已知值（如
1.0f），读回后用std::abs(d - 1.0) > 1e-6判定是否失真 - 编译期断言不够：
static_assert(std::numeric_limits<float>::is_iec559, "...")</float>只保证标准宣称，不保实现 - 如果目标平台不可控（如客户提供的工控设备 SDK），建议协议层改用文本或自定义定点格式，避开浮点二进制直写
实际最难的不是怎么转，而是得同时盯住三件事：内存视图转换是否无损、端序翻转方向是否和协议约定一致、以及 IEEE 754 实现是否真的一致——漏掉任意一个，数据就无声无息地错了。
