用std::ofstream二进制写vector最高效，需用binary模式、先写固定大小长度头（如uint64_t）、再写data()内存块，注意跨平台字节序与size_t兼容性。
用 std::ofstream 配合 write() 直接写内存块最省事
只要 vector 不含指针、虚函数或自定义析构逻辑（double 完全满足），它底层就是连续的 double 数组，可以直接按字节 dump。别转成字符串、JSON 或逐个写——那是自找慢。
实操建议：
- 打开文件必须用
std::ios::binary模式，否则 Windows 下换行符会被悄悄替换，读出来就错 - 先写长度（
size_t），再写数据，否则读取时不知道该读多少个double - 用
data()获取首地址，别用&v[0]——当v.empty()时前者安全，后者未定义行为
std::ofstream f("data.bin", std::ios::binary);
size_t n = v.size();
f.write(reinterpret_cast<const char>(&n), sizeof(n));
f.write(reinterpret_cast<const char>(v.data()), n * sizeof(double));</const></const>
读取时要注意 sizeof(size_t) 和字节序是否一致
写进去的长度是本机 size_t，如果文件要在不同平台（比如 x86_64 写、ARM32 读）间共享，size_t 大小可能不一致，直接读会崩。即使同架构，也要确认两端编译器对齐和大小一致。
常见错误现象：
- 读出的
n是巨大随机值（比如140737488355328），后续read()超长失败，vector分配巨量内存卡死 - 读出来的
double全是nan或极小值 —— 实际是字节序翻转了（比如大端写、小端读没处理）
简单对策：固定用 uint64_t 存长度，读写都用 htonll()/ntohll()（需自己实现或用 htobe64() 等），但若只在同环境读写，跳过也行。
别用 std::fstream::seekp() 在中间改写，除非你手动管理偏移
二进制文件不是数据库，没有“按索引更新第 5 个 double”这种原子操作。想改某几个值，常见误区是：
- 用
seekp(pos)定位后直接write()—— 如果pos计算错（比如忘了sizeof(uint64_t)的头长度），就会覆盖长度字段或相邻数据 - 以为
vector写完还能像数组一样“随机写”，结果发现文件末尾多了一堆\x00（因为seekp()超出当前长度时，中间自动补零）
真实场景中，如需频繁修改，不如整块读入、改内存、再整块写出；真要追加，确保每次都在 eof 位置，并重新写长度头。
跨平台移植时，double 的二进制表示基本可靠，但得避开 NaN 的 payload 差异
IEEE 754 规定了 double 的布局，主流平台（x86、ARM、RISC-V）都遵守，所以直接 memcpy 字节通常能互通。唯一坑点是 NaN：标准允许任意 payload，GCC/Clang/MSVC 生成的 quiet NaN 可能 bit 位不同，但数值比较仍为 false，不影响计算逻辑。
如果你的业务依赖 NaN 的具体 bit 模式（比如用 payload 编码类型），那就不能裸写，得序列化成固定格式（如 uint64_t + 标志位）。
其他兼容性注意点：
- 别依赖
std::numeric_limits<double>::is_iec559</double>运行时检查 —— 它几乎总是true，但查了也没用 - 不用
long double，它的大小和布局在平台间差异太大（x86_64 是 80-bit 扩展精度，aarch64 通常是 64-bit）
二进制写 vector<double></double> 本身很简单，真正的复杂点藏在“谁来读”和“什么时候读”里——尤其是当文件要被 Python（np.fromfile()）、MATLAB 或另一个 C++ 进程读取时，头结构、字节序、size_t 长度这些细节，漏一个就卡半天。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
