std::bitset 不适合海量数据去重，因其编译期固定大小、运行时无法扩容、内存全量分配且不支持高效遍历已置位索引。
为什么 std::bitset 不适合海量数据去重
它在编译期就要求确定大小，比如 std::bitset 会直接让编译器报错或生成超大目标文件；运行时无法动态扩容，内存占用是“全量分配”，哪怕只用了其中千分之一的位，也要占 125MB（10⁹ bit ≈ 125MB）。更关键的是，它不支持稀疏场景下的快速查找——你没法高效地遍历所有已置位的索引。
用 roaringbitmap 替代手写位图的三个硬理由
自己实现一个支持 64 位整数 ID、百亿级规模、内存可控、查询 O(1) 的位图，99% 的项目没必要——轮子早被压平了。Rust 和 Go 都有成熟移植，C++ 推荐直接用 CRoaring（C 接口，C++ 可无缝调用）：
- 自动分层：对连续段用
run编码，对稀疏段用array，对密集段用bitmap，空间比纯 bitmap 低 5–20 倍 -
add()/contains()平均 O(log n)，但实际因 cache 局部性常接近 O(1) - 支持序列化到磁盘（
roaring_bitmap_serialize()），重启后可roaring_bitmap_deserialize()恢复，不用每次重算
roaring_bitmap_t* 初始化与线程安全要点
它默认不是线程安全的，多线程写入必须加锁，但读可以无锁（只要没人在改）。常见错误是反复 roaring_bitmap_create() 却忘了 roaring_bitmap_free()，导致内存泄漏——尤其在长周期服务中。
推荐初始化方式：
roaring_bitmap_t *rb = roaring_bitmap_create(); // 若需预估容量（减少 rehash），可用： // roaring_bitmap_t *rb = roaring_bitmap_create_with_capacity(1000000); // 插入： roaring_bitmap_add(rb, 123456789L); roaring_bitmap_add(rb, 987654321L); // 查询： bool exists = roaring_bitmap_contains(rb, 123456789L); // true
注意：roaring_bitmap_add() 接收 uint32_t，若 ID 是 int64_t（如时间戳+随机数拼接），必须确保高位为 0，否则截断出错；如需真正 64 位支持，得用 roaring64_bitmap_t（CRoaring v0.4+），接口名带 64 后缀，底层用 map-of-roaring 结构。
从文件批量加载时避免 OOM 的关键操作
直接把上亿个 ID 读进 vector 再逐个 add()，容易触发频繁内存重分配和缓存抖动。正确做法是分块 + 预排序 + 批量构建：
- 每 10 万条 ID 读入后先
std::sort()去重（std::unique()），再用roaring_bitmap_from_uint32_array()一次性构造子 bitmap - 最后用
roaring_bitmap_or_inplace()合并，比逐个 add 快 3–5 倍 - 如果原始数据在磁盘且有序（如日志按时间递增），跳过 sort，直接流式 add —— CRoaring 内部对有序插入有小优化
真正棘手的不是性能，而是“去重边界”：ID 是否全局唯一？是否要跨天/跨进程去重？这些业务逻辑决定了 bitmap 是该单例持有，还是按日期分片存储——后者虽增管理成本，但避免单个 bitmap 膨胀失控。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
