多维数组用write写文件前必须确认内存连续且为POD类型，否则易因填充、非连续布局或非平凡类型导致数据错乱；正确做法是write(fd, &arr0, sizeof(arr))并调用fsync确保落盘。
多维数组用 write 写文件前，必须确认内存连续
直接对 int arr[3][4] 调用 write(fd, arr, sizeof(arr)) 看似合理，但只在「行优先、无填充、POD 类型」下才安全。C++ 多维数组本质是数组的数组，arr 退化为指向首元素（即 int[4]）的指针，而 write 只管字节流——它不关心语义，只按你给的地址和长度拷贝内存。
常见错误现象：read 回来后数据错位、部分值全零、甚至读到随机垃圾值。根本原因不是 write 有问题，而是你以为连续的地方其实有对齐填充，或你传了错误的起始地址。
- 二维
int arr[3][4]是连续的（标准保证），但struct S { int a; double b; } arr[3][4]不一定——成员对齐可能引入填充 -
std::vector<:vector>></:vector>绝对不连续；每个内层vector单独堆分配 - 用
sizeof(arr)没问题，但用sizeof(*arr)或sizeof(arr[0])得小心：它们是int[4]的大小，不是单个int
write 写多维数组时，指针类型和长度必须严格匹配
别依赖“自动转换”。write 第二个参数是 const void*，编译器不会帮你校验类型尺寸。你传 (char*)arr 还是 (char*)&arr[0][0]，结果一样；但传 (char*)arr[0] 就只写第一行——这是最常踩的坑。
使用场景：需要快速 dump 数值计算结果（如图像像素、矩阵数据），且后续由同构程序读取。不适合跨平台或长期存档，因为字节序、对齐、类型尺寸都未标准化。
立即学习“C++免费学习笔记（深入）”；
- 正确写法：
write(fd, &arr[0][0], sizeof(arr));或write(fd, arr, sizeof(arr));（两者等价） - 错误写法：
write(fd, arr[0], sizeof(arr));——arr[0]是int[4]，强制转char*后只取前 4 字节参与运算，sizeof(arr)却仍是 48，导致越界读内存 - 若用
std::array<:array>, 3></:array>，同样适用，因为它是聚合类型，无额外开销
结构体数组含非 POD 成员时，write 会静默写坏数据
只要结构体里有 std::string、std::vector、虚函数、用户定义构造/析构，就不能直接 write 整个对象。此时 write 拷的是指针值（比如 std::string 内部的 char*），而不是它指向的字符串内容——文件里存的是一串无意义地址，读回来毫无用处。
性能影响：看似一次 write 很快，但读取时要重建对象状态，反而更慢、更易出错。兼容性上，这类二进制格式完全不可移植。
- 检查方法：用
std::is_trivially_copyable_v<t></t>编译期断言，不满足就别碰write - 替代方案：手动序列化字段，例如循环写
obj.x、obj.y；或用memcpy拷贝 POD 部分，再单独处理动态成员 - 错误示例：
struct Bad { std::string s; int x; }; Bad arr[10]; write(fd, arr, sizeof(arr));—— 文件里s对应位置是随机指针值
写入后没 fsync 或关闭文件，可能丢数据
Linux/Unix 下 write 默认只进内核页缓存，不落盘。断电、崩溃或进程被杀时，刚写的数据可能永远消失。这不是 C++ 特有，但多维数组通常体积大，缓存延迟更明显。
容易被忽略的地方：很多人以为 close() 就够了，其实 close 不保证同步——它只是释放 fd，内核可能继续异步刷盘。POSIX 明确说 close 不同步元数据或数据。
- 稳妥做法：写完调
fsync(fd)，再close(fd) - 如果用
FILE*（如fwrite），对应的是fflush(fp)+fsync(fileno(fp))+fclose(fp) - 注意
fsync可能阻塞较久，尤其在机械盘或高负载时；若追求吞吐，可考虑O_SYNC标志打开文件，但每次write都同步，开销更大
write 从不替你思考类型，它只相信你给的地址和长度；而磁盘那头，永远比你以为的更不靠谱。 
