不能直接 fwrite 含指针的 struct，因为指针值仅在当前进程地址空间有效，写入后读取会得到无效地址，解引用导致段错误；必须通过偏移、ID映射或序列化库（如boost::serialization）安全处理指针关系。
为什么不能直接 fwrite 一个含指针的 struct
因为指针值（比如 0x7fffa1234567）只在当前进程地址空间有效，换进程、换机器、甚至下次运行时都大概率失效。直接 fwrite 整个结构体，写进去的是“虚地址”，读出来后 memcpy 回来也还是野指针，一解引用就 Segmentation fault。
常见错误现象：valgrind 报 Invalid read of size 8，或程序在反序列化后访问某字段时崩溃，但调试发现指针非空——只是指向了非法内存。
- 所有指针字段必须转为“可重定位”的描述：比如用相对偏移、索引 ID、或独立序列化 + 重建映射表
- 若结构中存在循环引用（A→B→A），必须显式记录节点首次出现位置，避免无限递归或重复分配
- 不建议手写二进制格式；优先用带图遍历能力的序列化库，否则极易漏掉某个分支指针
用 boost::serialization 处理多级指针和共享对象
它内置图序列化（graph serialization）机制，能自动识别同一对象被多个指针引用、或循环引用的情况，序列化时只存一份数据 + 引用标记，反序列化时重建指针关系。
使用场景：你有一组 Node* 构成的树/图，节点间有父子、兄弟、甚至回溯指针，且某些节点被多个 parent 指向。
立即学习“C++免费学习笔记（深入）”；
- 必须为每个类显式定义
serialize成员函数，并用ar & member;逐字段注册（包括指针成员） - 指针字段要声明为
std::shared_ptr<T>或T*，boost::serialization才能识别并管理其生命周期 - 若用裸指针
T*，需确保所指对象也在同一归档中被序列化（不能是栈变量或全局变量） - 反序列化前，目标对象内存由库自动 new 出，无需手动
new；但要注意析构顺序和所有权归属
示例关键片段：
template<class Archive>
void serialize(Archive& ar, const unsigned int version) {
ar & id;
ar & name;
ar & parent; // 假设是 std::shared_ptr<Node>
ar & children; // std::vector<std::shared_ptr<Node>>
}
自己实现时如何安全处理指针偏移与重定位
如果不用第三方库，核心思路是两阶段：第一阶段遍历全图，给每个对象分配唯一 ID 并记录原始地址 → 偏移映射；第二阶段按 ID 顺序写入数据块，指针字段全替换成对应 ID；加载时先分配所有对象，再批量修正指针字段。
容易踩的坑：sizeof(T) 不等于实际序列化大小（因对齐、vptr、或 padding）；reinterpret_cast<char*>(ptr) 直接写会跳过虚函数表等元信息。
- 所有对象必须以 POD 或显式内存布局（
#pragma pack(1)）方式定义，禁用虚函数和非平凡构造函数 - 写入前用
memcpy拷贝到连续 buffer，而非直接fwrite(&obj, sizeof(obj), 1, fp) - ID 映射表本身也要序列化（如写在文件头），且 ID 类型建议用
uint32_t而非指针宽度类型，保证跨平台兼容 - 恢复时，指针修正必须在所有对象内存分配完毕后统一进行，不能边读边连——否则引用未分配的对象
std::unique_ptr 和 std::shared_ptr 在序列化中的行为差异
std::unique_ptr 表示独占所有权，序列化时只能保存其所指对象的副本（deep copy），无法共享；std::shared_ptr 则允许跨对象共享同一份数据，序列化器需识别引用计数逻辑并重建共享关系。
性能影响：共享对象越多，std::shared_ptr 的图序列化开销越明显（需维护 ID 映射哈希表）；而 std::unique_ptr 虽无共享开销，但深拷贝可能带来冗余存储和内存放大。
-
boost::serialization对std::shared_ptr有原生支持，对std::unique_ptr也支持，但不会做跨指针去重——每个unique_ptr都会独立序列化其内容 - 若业务逻辑上本应共享，却误用
unique_ptr，会导致反序列化后出现多份相同数据，修改一处不影响其他，违背原意 - 自定义序列化时，切勿尝试序列化
std::shared_ptr的控制块（control block），它包含运行时地址，必须丢弃并重建
