直接reinterpret_cast写入二进制仅对标准布局类型安全，需static_assert验证；含std::string等非pod成员须手动序列化；注意内存对齐、跨平台字节序与类型宽度，推荐固定宽度类型和逐字段写入。
用 std::ofstream 写裸内存前，先确认对象是标准布局
直接 reinterpret_cast<char>(&obj)</char> 写入二进制，只对标准布局类型（POD 或满足 std::is_standard_layout_v<t></t>）安全。有虚函数、非公有继承、非公有成员、或含引用/非平凡构造/析构的类，这么干会读出乱码甚至崩溃。
- 检查方法：
static_assert(std::is_standard_layout_v<mystruct>, "not standard layout");</mystruct> - 常见陷阱：加了个
std::string成员就立刻失效——它内部指针在反序列化后指向无效地址 - 替代方案：若必须含
std::string，得手动序列化其.data()和.size()，再单独写字符串内容
手写序列化时，sizeof(T) 不等于实际存储长度
结构体有内存对齐，sizeof(MyStruct) 可能比字段字节和大很多。比如两个 char 中间插个 int，编译器可能补 3 字节空洞。直接按 sizeof 读写，跨平台或换编译器就错。
- 解决办法：用
#pragma pack(1)强制紧凑对齐（注意性能损耗），或用alignas(1)显式声明 - 更稳妥做法：逐字段序列化，比如
out.write(reinterpret_cast<const char>(&x.a), sizeof(x.a));</const> - 别信 IDE 的“结构体大小提示”，它不反映你运行时实际写的字节数
跨平台保存时，int 和 float 的字节序和尺寸不能默认一致
x86 和 ARM 默认小端，但某些嵌入式平台是大端；int 在 Windows/MSVC 是 4 字节，但在某些旧嵌入式环境可能是 2 字节；float 虽然 IEEE 754 普遍支持，但 denormal 数处理可能不同。
- 关键动作：统一用固定宽度类型，如
int32_t、uint8_t、float32_t（需<cstdint></cstdint>和<cfenv></cfenv>） - 字节序转换：写前用
htons()/htonl()，读后用ntohs()/ntohl()；C++23 起可用std::byteswap - 测试点：在目标平台编译并用
std::endian::native == std::endian::big现场判断
想省事用 boost::serialization？先看清它的二进制档案不是“裸数据”
boost::archive::binary_oarchive 输出的是带元信息的二进制流，含类型名、版本号、指针偏移等，不是纯字段拼接。这意味着：
立即学习“C++免费学习笔记（深入）”；
- 不能用其他语言解析，也不能用
xxd直接看字段值 - 同一类在 Boost 版本升级后可能无法反序列化旧文件（除非显式设
BOOST_CLASS_VERSION） - 体积比裸写大 20%~50%，且初始化开销明显，高频小对象场景慎用
- 如果真要它，记得关掉跟踪：
ar & BOOST_SERIALIZATION_NVP(obj);前加ar.disable_tracking<mytype>();</mytype>
最易被忽略的一点：序列化不是存档，而是契约。一旦写入磁盘，字段增删、类型变更、甚至注释调整（影响 static_assert），都可能让老数据永远无法加载。别把序列化格式当成临时便利，它和 API 一样需要版本管理和向后兼容设计。
