直接用 memcpy 写入原始内存是错的，因指针地址失效且标准库实现不兼容；应只序列化键值和元信息，加载时新建容器并逐个 insert，配合 reserve 提升性能。
直接用 memcpy 写入原始内存是错的
很多人第一反应是把 std::unordered_set 的底层桶数组或节点指针块 memcpy 到文件里，这会导致严重问题：容器内部存储的是指针（如 Node*）、哈希桶索引、可能还有分配器状态，这些地址在下次加载时完全无效；而且不同标准库实现（libstdc++ / libc++ / MSVC）内存布局不兼容，甚至同一版本 debug/release 模式下结构都可能不同。
必须序列化为可移植的扁平结构
核心思路是：只保存键值本身 + 元信息（元素数量、哈希函数参数等），不保存任何指针或内部节点结构。假设键类型是 POD（如 int、std::string、std::array<uint8_t></uint8_t>），且你控制读写两端的编译环境（同平台、同字节序、同 ABI）：
-
std::string需单独处理：先写长度（uint32_t），再写字符数据 - 自定义结构体需确保无虚函数、无指针成员、
static_assert(std::is_trivially_copyable_v<t>)</t>成立 - 哈希表负载因子和桶数不必保存——加载后重建即可，用
reserve()预分配提升性能
示例（键为 int）：
std::ofstream f("set.bin", std::ios::binary);
size_t n = s.size();
f.write(reinterpret_cast<const char*>(&n), sizeof(n));
for (int x : s) {
f.write(reinterpret_cast<const char*>(&x), sizeof(x));
}
加载时不能直接构造，要逐个 insert
二进制文件里只有键序列，没有哈希桶信息，所以无法“原样恢复”内部结构。必须新建空 std::unordered_set，然后循环 insert。虽然比 memcpy 慢，但这是唯一安全方式：
立即学习“C++免费学习笔记（深入）”；
- 插入前调用
reserve(n)可避免多次 rehash，实测提速 2–5 倍 - 若键类型支持无序哈希（如
std::hash<int></int>），无需额外配置；自定义类型需确保std::hash<T>和operator==已正确定义 - 不要尝试用
std::vector中转再用insert(begin, end)—— 这不会比循环 insert 快，且多占一倍内存
加载代码：
std::ifstream f("set.bin", std::ios::binary);
size_t n;
f.read(reinterpret_cast<char*>(&n), sizeof(n));
std::unordered_set<int> s;
s.reserve(n);
for (size_t i = 0; i < n; ++i) {
int x;
f.read(reinterpret_cast<char*>(&x), sizeof(x));
s.insert(x); // 或 emplace_hint(s.end(), x) 略微优化
}
跨平台或长期存档必须用协议缓冲或 msgpack
如果文件要被不同架构（ARM/x86）、不同编译器或未来版本读取，裸二进制不可靠：整数大小、对齐、浮点表示、std::string 内存布局都可能变化。此时应放弃手写二进制，改用成熟序列化方案：
-
protobuf：定义.proto文件，生成 C++ 类，天然支持版本兼容和字段可选 -
msgpack：轻量、无 schema、C++ 接口简洁，std::unordered_set<int>可直接 pack/unpack - 别自己造“小端/大端标记”或“版本号头”——这些细节极易出错，且维护成本远超引入一个 header-only 库
真正难的不是怎么写进文件，而是怎么让读出来的集合语义不变：哈希策略一致、相等判断一致、内存安全。这点常被忽略，直到在客户机器上 find() 总返回 end() 才发现。
