不能直接用 memcpy 复制嵌套结构体，因其可能含指针、虚函数表、非 pod 类型或不可控 padding，导致反序列化失败、跨平台不兼容或解包错位。
为什么不能直接用 memcpy 复制嵌套结构体
因为嵌套结构体通常含指针、虚函数表、非 POD 类型（如 std::string、std::vector），或存在内存对齐填充。直接 memcpy 会把指针地址写进字节流，反序列化时读出来的只是野地址，不是原数据。
哪怕全是 POD 成员，若有嵌套结构体成员且未显式指定 [[no_unique_address]] 或手动 pack，编译器插入的 padding 字节也不可控，跨平台/跨编译器序列化会失败。
- 检查是否为 POD：用
std::is_pod_v<t></t>（C++17 起已弃用，改用std::is_trivially_copyable_v<t></t>+std::is_standard_layout_v<t></t>） - 即使满足 trivially copyable，只要含子结构体，其内部 padding 仍可能因编译器或目标平台不同而变化
- 常见错误现象：
sizeof(Outer) != sizeof(A) + sizeof(B)，但你按字段顺序硬拼接，结果解包错位
手动逐字段序列化：最可靠但易出错的方案
适用于已知结构稳定、无动态分配成员、需最小依赖的场景（如嵌入式通信、游戏网络同步）。核心是放弃“一块内存搞定”，改用确定性字段遍历。
示例结构：
struct Vec3 { float x, y, z; };
struct Transform { Vec3 pos; Vec3 rot; int id; };
struct Entity { Transform t; char name[32]; uint64_t timestamp; };
正确扁平化方式：
- 用
std::vector<uint8_t></uint8_t>作为输出缓冲区，调用reserve()避免多次 realloc - 每个字段用
reinterpret_cast<const uint8_t>(&field)</const>取地址，配合sizeof(field)追加 - 数组（如
char name[32]）直接按 size 拷贝；子结构体（如Transform）递归展开，不调memcpy(&t, ...) - 注意字节序：若需跨平台，所有多字节整数/浮点数必须转为网络序（
htons/htonl/std::byteswap）
用 std::span<const std::byte></const> 包装原始内存时的陷阱
有人尝试把结构体地址转成 std::span<const std::byte></const> 当字节流用——这仅在结构体是标准布局（standard layout）、且所有成员类型都 trivially copyable 时才安全，且仍要处理 padding。
- 错误写法：
auto span = std::span{reinterpret_cast<const std::byte>(&e), sizeof(e)}</const>—— 若Entity有 padding，span 包含了不可控的垃圾字节 - 正确做法：先用
offsetof和sizeof算出每个字段偏移和长度，只拷贝有效字段区域，跳过 padding - 工具辅助：Clang/GCC 的
__attribute__((packed))可消除 padding，但会破坏性能（非对齐访问），且不保证跨编译器一致；更稳妥的是用#pragma pack(1)并在头尾加保护
何时该放弃手写，改用序列化库
一旦结构体含 std::string、std::vector、std::optional、继承关系或运行时多态，手写序列化成本指数上升，出错概率远高于收益。
-
protobuf：需定义.proto文件，生成 C++ 类，天然支持嵌套、可选字段、向后兼容；缺点是二进制格式不透明，调试困难 -
msgpack：header-only，支持 STL 容器，通过宏注册结构体（MSGPACK_DEFINE(pos, rot, id)），自动处理嵌套；但不校验字段名变更 - C++20 起可考虑
std::bit_cast配合自定义 layout，但仅限 trivially copyable 类型，且无法解决动态大小问题
真正容易被忽略的是：嵌套层级深时，字段命名冲突、版本迁移、默认值语义（比如 std::optional<int></int> 是空还是 0）这些逻辑，永远比 memcpy 多 10 倍代码量来维护。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
