直接读写struct会出错，因编译器填充、成员重排、对齐差异导致内存布局不固定；需用#pragma pack(1)或alignas(1)控制对齐，禁用非pod类型，检查trivially_copyable，处理字节序与缓冲刷新。
read/write 直接读写 struct 会出错，因为内存布局不固定
用 read() 和 write() 对自定义 struct 做二进制 I/O，看似简单，实际大概率读出来是乱码或崩溃。根本原因是 C++ 不保证 struct 的内存布局：编译器可能自动插入填充字节（padding），成员顺序可能被重排，不同平台/编译器的对齐规则也不同。
常见错误现象：read() 后字段值全为 0、负数异常、sizeof(MyStruct) 和你手算的不一致、跨平台读写失败。
- 必须显式控制对齐：用
#pragma pack(1)或alignas(1)消除 padding（注意：这会降低访问性能） - 禁止含指针、虚函数、std::string、std::vector 等非 POD 类型 —— 它们无法直接二进制序列化
- 确认所有成员都是 trivially copyable：可用
static_assert(std::is_trivially_copyable_v<mystruct>)</mystruct>编译期检查 - 结构体里有浮点数？注意 IEEE 754 格式虽通用，但某些嵌入式平台可能不兼容
write 后没 flush，数据可能根本没写到磁盘
write() 是系统调用，但底层文件描述符可能带缓冲；std::ofstream::write() 更是默认走 streambuf 缓冲。没显式刷新就 close 或程序退出，最后几 KB 数据大概率丢失。
使用场景：日志落盘、关键配置保存、实时传感器数据写入。
- 用
fd（文件描述符）时：调用fsync(fd)强制刷盘（Linux/macOS），Windows 用FlushFileBuffers(hFile) - 用
std::ofstream时：在write()后加os.flush()，再os.close()；更稳妥的是设成无缓冲：os.rdbuf()->pubsetbuf(nullptr, 0) - 别依赖析构函数自动 flush —— 异常中途退出时，析构可能不执行
read 返回值不检查，程序会静默读错或卡死
read() 和 std::istream::read() 都不抛异常，返回值才是唯一真相。忽略它，等于假设每次都能读满预期字节数 —— 实际上文件末尾、磁盘错误、网络中断都会导致少读。
错误现象：结构体部分字段未初始化、后续解析逻辑崩坏、程序 hang 在阻塞 read 上（尤其 socket 场景）。
-
read(fd, buf, size)返回ssize_t：-1 是错误（查errno），0 是 EOF，其他值是实际读取字节数 -
is.read(buf, size)后必须立刻检查：if (!is.gcount()) { /* 0 字节 */ }或if (is.fail()) { /* 错误 */ } - 不要用
while (is.read(...))—— 这会在 EOF 时把流置为 failbit，后续gcount()返回 0，循环直接退出，但最后一次有效读的数据已丢失 - 批量读复杂结构时，建议按块读（如 4KB），再用
memcpy拆包，避免单次 read 跨结构边界
跨平台读写 uint32_t 等类型，字节序不统一就全乱
x86 是小端，ARM 可能大端，网络协议通常要求大端（network byte order）。直接 write() 一个 uint32_t，在另一台机器上 read() 出来就是反的。
使用场景：存档文件共享、嵌入式设备与 PC 通信、游戏存档兼容性。
- 统一用网络字节序（大端）存盘：写前用
htonl(x)，读后用ntohl(x)；uint16_t用htons()/ntohs() - 别用
reinterpret_cast<char>(&x)</char>直接转 —— 这绕过字节序转换，只适合本机回读 - 如果格式需长期稳定，建议在文件头写 magic number + version + endianness flag，运行时校验再决定是否翻转
- 现代替代方案：用
std::byteswap（C++23）或__builtin_bswap32（GCC/Clang），比 ntohl 更泛用
最麻烦的不是怎么写，而是“什么时候意识到要处理字节序”——等两个平台数据对不上，再回头改，往往要重刷所有旧文件。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
