std::unordered_set不能直接序列化，必须手动遍历；标准库未提供operator
std::unordered_set 不能直接序列化，必须手动遍历
标准库没提供 operator 或 serialize() 接口，底层哈希表结构（桶数组 + 链表/红黑树节点）不保证内存连续，也不能靠 memcpy 整体拷贝。你得自己拆开：先写元素个数，再逐个写每个 value_type。
- 常见错误：直接
write(reinterpret_cast—— 这只写了控制块（如桶指针、size），不是数据本身，读出来必崩(&s), sizeof(s)) - 使用场景：进程间共享缓存、快速冷启动加载、日志快照等对读写性能敏感的场合
- 注意
std::unordered_set的键类型必须是 trivially copyable（如int、std::string需特殊处理），否则二进制写入无意义
写入时要处理 std::string 等非 POD 类型
std::string 在内存中是三字长结构（指针+长度+容量），直接二进制 dump 指针地址毫无用处；必须先写长度，再写字符数据。
- 示例：对
std::unordered_set<:string>，每个元素需写uint32_t len+len字节的c_str() - 若含嵌套容器（如
std::unordered_set<:vector>>），同样要递归处理：先写size()，再循环写每个int - 别忽略字节序 —— 跨平台存储时，统一用
htole32()/le32toh()（Linux/macOS）或手动翻转，否则在 PowerPC 或旧 ARM 上读错
读取时必须严格按写入顺序反向还原
二进制流没有元信息，读端完全依赖你写的协议。少读一个 uint64_t，后面所有解析全偏移。
- 典型错误：写入用
size_t记个数，读时用uint32_t读 —— 在 64 位系统上可能截断，导致后续循环次数错误 - 建议固定用
uint32_t存大小（上限 42 亿，够用），元素类型用明确宽度类型（int32_t、uint64_t） - 读取失败时不要静默跳过 —— 至少校验总字节数是否匹配，或加简单 CRC32（哪怕只校验 header），避免静默数据损坏
std::unordered_set 插入性能不受影响，但序列化后无法保持原哈希分布
导出的是逻辑集合，不是物理布局。重新 load 后，insert() 会按新环境的哈希函数和桶数重建结构，插入 O(1) 均摊复杂度不变，但首次查询可能略慢（rehash 开销）。
- 如果追求极致加载后查询性能，可在写入时额外保存当前
bucket_count()和load_factor()，读取后调用reserve()和max_load_factor()预配置 - 别试图保存迭代器或节点指针 —— 它们生命周期只在单次运行内有效，二进制里存了也毫无意义
- 多线程写入时，确保
std::unordered_set未被修改 —— 二进制导出不是原子操作，中途改数据会导致流内容不一致
事情说清了就结束。最常漏掉的是字符串长度字段和字节序，这两处一错，整个流就废了。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
