只有POD结构体才能安全memcpy；需满足无虚函数、无非静态成员函数、无用户定义构造/析构/赋值、所有成员也均为POD，否则须手写序列化逻辑。
直接 memcpy 可能出问题，先确认结构体是否满足 POD
不是所有结构体都能安全 memcpy 成二进制流。C++ 要求类型是 POD（Plain Old Data）：不能有虚函数、非静态成员函数、私有/保护非静态数据成员、用户定义构造/析构/赋值函数，且所有成员本身也必须是 POD。
常见踩坑点：
- 结构体里加了
std::string或std::vector→ 直接memcpy会把指针地址写进去，反序列化后读的是野指针 - 用了
#pragma pack(1)但没在接收端用同样对齐 → 字节序和偏移错乱 - 结构体含浮点数或指针，在不同平台（如 x86 vs ARM）上可能因 ABI 差异导致位宽或字节序不一致
简单 POD 结构体：用 reinterpret_cast + memcpy 最快
若确认结构体是 POD（比如纯 C 风格的 struct Packet { uint32_t len; uint16_t id; char data[64]; };），可直接转为 char* 流：
Packet pkt = {1024, 123, "hello"};
char buf[sizeof(Packet)];
memcpy(buf, &pkt, sizeof(Packet));
// 发送 buf，或存入文件
反序列化同理：
立即学习“C++免费学习笔记（深入）”；
Packet* p = reinterpret_cast<Packet*>(buf); // 注意：buf 生命周期必须长于 p 的使用期；不要用 static_cast 替代 reinterpret_cast
关键提醒：
- 发送前确保
sizeof(Packet)在收发两端完全一致（检查编译器、打包指令、对齐方式） - 避免跨平台直接传浮点字段——
float在 IEEE754 下虽通用，但某些嵌入式平台不保证 - 别对含 bit-field 的结构体这么做，位域布局无标准保证
含 STL 容器或非 POD 成员？必须手写序列化逻辑
例如结构体带 std::string name 和 std::vector<int> ids，就不能整体拷贝。得拆开处理：
- 先写固定头：如
uint32_t name_len，再写name.data()的原始字节 - 再写
uint32_t ids_size，然后逐个写ids[i]（注意 endianness） - 接收端严格按相同顺序读：先读长度，再 malloc/resize，再读数据块
示例片段（简化版）：
void serialize(const MyStruct& s, std::vector<char>& out) {
uint32_t len = htonl(static_cast<uint32_t>(s.name.size())); // 网络序
out.insert(out.end(), reinterpret_cast<const char*>(&len),
reinterpret_cast<const char*>(&len) + sizeof(len));
out.insert(out.end(), s.name.begin(), s.name.end());
}
注意：htonl / ntohl 仅对整数有效，且只解决字节序，不解决大小端对齐差异（如 long 在 Windows 和 Linux 可能是 4 或 8 字节）。
跨语言或长期存储？别手撸，用 Protocol Buffers 或 flatbuffers
如果结构体要被 Python/Java 读取，或需向前兼容（比如新增字段不影响旧版本解析），硬编码二进制格式很快失控。这时候：
-
protobuf：定义.proto文件，生成 C++ 类，自带SerializeToArray和ParseFromArray -
flatbuffers：零拷贝、无需解析步骤，适合高频低延迟场景，但要求结构体字段全为 POD 或 flatbuffers 内置类型 - 避免用
boost::serialization：它依赖运行时类型信息和 operator<< 重载，生成的二进制不跨语言、不易调试
真正容易被忽略的一点：即使你控制全部代码，只要未来可能加日志回放、网络协议升级、或导出数据给数据分析脚本，二进制格式就必须带 magic number + version 字段 —— 否则某天 sizeof(MyStruct) 变了，老数据就永远读不出来了。
