直接用write()写结构体读出来错，因存在内存对齐填充（padding）且非POD类型（如std::string）仅存指针，导致数据错乱或崩溃；应手动序列化或仅用于纯POD结构体。
直接用 write() 写结构体，为什么有时读出来是错的？
因为结构体可能有内存对齐填充（padding），sizeof(MyStruct) 不一定等于所有成员大小之和。如果结构体含指针、std::string、std::vector 等非 POD 类型，直接二进制写入会保存指针地址或内部无效句柄，读取时必然崩溃或数据错乱。
实操建议：
- 仅对纯 POD（Plain Old Data）结构体使用
write()/read()，例如只含int、double、char[32]等固定大小、无构造/析构的成员 - 用
static_assert(std::is_pod_v<mystruct>)</mystruct>在编译期确认，避免后期踩坑 - 显式禁用对齐（如
#pragma pack(1)）可消除 padding，但需两端一致，且影响性能——仅在协议固定、跨平台交换时谨慎启用
如何安全支持含 std::string 的结构体序列化？
必须手动拆解：把 std::string 的长度和字符内容分两步写入，读取时先读长度、再按长度分配并读字符。不能依赖 sizeof(string) 或直接 memcpy。
示例关键逻辑：
立即学习“C++免费学习笔记（深入）”；
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
struct Person {
int id;
std::string name;
};
<p>// 写入
out.write(reinterpret_cast<const char<em>>(&p.id), sizeof(p.id));
size_t len = p.name.size();
out.write(reinterpret_cast<const char</em>>(&len), sizeof(len));
out.write(p.name.c_str(), len);</p><p>// 读取
in.read(reinterpret_cast<char<em>>(&p.id), sizeof(p.id));
size_t len;
in.read(reinterpret_cast<char</em>>(&len), sizeof(len));
p.name.resize(len);
in.read(&p.name[0], len);
注意：std::string::data() 在 C++17 前不保证以 \0 结尾，用 c_str() 更稳妥；resize() 后直接取 [0] 地址是安全的（C++11 起保证连续存储）。
封装读写函数时，为什么推荐用 std::streambuf* 而非 std::ofstream？
用 std::ofstream 参数会绑定具体文件，难以复用到内存流（std::stringstream）、网络 socket 缓冲区或自定义加密流。而 std::streambuf* 是底层接口，更灵活、零成本抽象。
实操建议：
- 序列化函数签名优先设计为：
bool serialize(const Person& p, std::streambuf* sb) - 调用侧可自由选择：
serialize(p, file_ofstream.rdbuf())或serialize(p, mem_stream.rdbuf()) - 务必检查
sb->sputn()返回值是否等于期望字节数，sb->snextc() == EOF可判断读取提前结束
跨平台读写二进制文件，最容易被忽略的三个点
不是“能不能读”，而是“读得对不对”。尤其在 Windows/Linux/macOS 之间交换文件时：
-
int大小不统一：用int32_t/uint64_t替代裸int，避免 32 位 vs 64 位平台差异 - 字节序（endianness）：x86 是小端，部分嵌入式平台是大端。若需兼容，统一转为网络序（
htons/htonl），读取时再转回主机序 - 文本换行符干扰：确保文件以
std::ios::binary模式打开，否则 Windows 下\n可能被误转成\r\n，破坏二进制布局
实际项目中，哪怕只在同架构 Linux 服务器间传输，也建议加一个 4 字节 magic header（如 0x12345678）和版本号字段——下次结构体加字段时，立刻知道旧文件能否加载，而不是靠崩溃倒推。
