直接写类对象指针会写入其内存地址（如0x7ffeed12a9b8），而非对象数据；该地址下次运行无效，读取将导致段错误、乱码或不可预测行为。
直接 write 类对象指针会写进去什么？
写进去的是指针变量本身的值——也就是一个内存地址（比如 0x7ffeed12a9b8），不是它指向的对象数据。这个地址在下次程序运行时大概率无效，甚至根本无法解析，读出来也毫无意义。
常见错误现象：read 后用该指针访问成员，触发段错误；或读出乱码、空值、崩溃；更隐蔽的是“看似正常”，实则读的是旧内存残留，行为不可预测。
- 指针本身是固定大小（如 8 字节），
write它就像写一个size_t，和类无关 - 如果类含
std::string、std::vector、虚函数表指针、动态分配的成员，这些内容根本不会被写入 - 即使类是 POD（纯数据）且你写的是对象本身（非指针），跨平台或不同编译器下也可能因对齐、字节序、padding 导致读写不一致
怎么安全地把类对象持久化到文件？
必须序列化对象的内容，而不是它的地址。核心思路：把对象的数据字段按确定格式转成字节流，再写入；反向操作还原。
推荐做法分三类，按复杂度递增：
立即学习“C++免费学习笔记（深入）”；
- 简单 POD 类：用
memcpy+write整个对象（需确保无指针、无虚函数、无标准容器），例如struct Point { int x, y; };可直接write(fd, &p, sizeof(p)) - 含标准容器或需跨版本兼容：手写
serialize()/deserialize()成员函数，逐字段处理（std::string先写长度再写内容） - 生产环境：用成熟序列化库，如
protobuf、flatbuffers或boost::serialization，它们自动处理版本、类型、内存布局等细节
示例（手动序列化小结构）：
struct Config {
int version;
std::string name;
void serialize(std::ostream& os) const {
os.write(reinterpret_cast<const char*>(&version), sizeof(version));
uint64_t len = name.size();
os.write(reinterpret_cast<const char*>(&len), sizeof(len));
os.write(name.c_str(), len);
}
};
std::ofstream 写对象时要注意什么？
别默认用文本模式。C++ 的 std::ofstream 默认是文本模式，会做换行符转换（\n → \r\n），破坏二进制数据完整性。
- 必须显式指定
std::ios::binary标志：std::ofstream f("data.bin", std::ios::binary); - 不要用
<<操作符写原始数据（它是为格式化文本设计的），改用write()： -
f.write(reinterpret_cast<const char>(&obj), sizeof(obj));</const>—— 仅适用于 POD - 若对象有虚函数或继承关系，
sizeof不等于实际数据大小，此时必须手写序列化逻辑
为什么 reinterpret_cast<char*> 容易出错？
它只是告诉编译器“把这块内存当 char* 看”，但不解决底层语义问题：对齐、padding、生命周期、const 正确性。
- 类有私有成员或访问控制时，
reinterpret_cast绕过封装，可能读到未初始化 padding 字节，导致校验失败或解包异常 - 使用
reinterpret_cast写对象后，若对象含std::unique_ptr等资源句柄，反序列化时不会重建资源，只会复制原始位模式，造成悬空或 double-free - 多态类（带虚函数）的 vptr 是编译器插入的，每次构造都不同，不能靠位拷贝恢复
真正需要的是明确的序列化契约：哪些字段存、怎么存、顺序如何、是否压缩/加密——这些 reinterpret_cast 一概不管。
最常被忽略的一点：序列化格式一旦写入文件，就构成接口契约。哪怕只是改了一个 int 字段为 long long，老版本程序读新文件就会错位，后续所有字段全乱。别想着“先跑通再说”。
