Bitmap仅适用于整数范围明确、非负且内存可控场景；std::vector因缺乏位操作支持、非原子性及调试困难等缺陷不宜直接用作Bitmap；手写uint64_t位图+原子fetch_or是高并发下可靠方案。
Bitmap 不是拿来就用的“去重万金油”，它只在整数范围明确、非负、且内存可承受时才比 std::unordered_set 更优；值域一超限，要么崩溃，要么浪费百倍内存，还可能静默越界写坏相邻变量。
为什么不能直接用 std::vector<bool></bool> 做 Bitmap
std::vector<bool></bool> 是代理类，不是真位容器：它不支持取地址（&v[i] 无效）、没有 data() 接口、迭代器解引用返回临时 reference、多线程下 operator[] 非原子——这些对位图核心操作全是硬伤。
- 压测显示，10 亿次
set()，它比手写std::vector<uint64_t></uint64_t>慢 3–5 倍 - 无法用
memcpy批量初始化或导出，也不能 mmap 映射到文件 - 调试时
gdb看不到原始字节布局，排查越界访问极其困难
手写 std::vector<uint64_t></uint64_t> Bitmap 的关键细节
每个 uint64_t 管 64 个 bit，用位运算直接控制，性能和可控性都在线。
- 索引计算必须用位运算：
idx >> 6替代idx / 64，idx & 63替代idx % 64，避免除法开销 - 左移字面量必须是
1ULL，否则1 在 int 下会溢出成负数 - 构造时按
(max_val + 63) / 64调用reserve()，防止多次 realloc 导致内存碎片 - 插入前必须校验
x ，否则越界写入会破坏后续 <code>uint64_t元素（C++ 不检查）
值域太大（如 uint64_t）时怎么分桶不翻车
全量分配不可行，但简单按高 K 位切桶容易丢精度或撞桶；得兼顾哈希均匀性和还原可行性。
立即学习“C++免费学习笔记（深入）”；
- 推荐两级策略：高位定桶（如
x >> 44得 4096 个桶），低位哈希定偏移（用 MurmurHash3 截断为 20 位） - 每个桶配
std::bitset（128 KB），总内存可控（约 512 MB），且支持编译期优化 - 不要用
x & 0xFFFFF直接截低 20 位——若原始数据低位高度重复（如时间戳毫秒部分），会导致严重哈希堆积 - 查询返回
false表示“一定没出现过”，返回true仅表示“可能见过”，这是概率模型，不是精确去重
并发插入时最容易被忽略的原子性陷阱
多个线程同时 set(x) 同一个 bit，不加防护会丢位——这不是竞态警告，是必然发生的数据丢失。
- 别锁整个 bitmap，吞吐归零；也别用
std::atomic_flag模拟自旋锁，它不支持位操作 - 实测最稳方案：声明
std::vector<:atomic>></:atomic>，每个元素对应一个uint64_t桶 - 插入时算出桶号
bucket = x >> 6，再调用bits[bucket].fetch_or(1ULL - 如果业务允许少量漏判（比如日志采样），改用线程局部 bitmap + 定期 merge，吞吐能再提 2×
真正卡住性能的往往不是算法本身，而是跨 cache line 访问：查 idx=127 会同时读第 1 和第 2 个 uint64_t，触发两次内存加载；这种边界 case 在批量查找中高频出现，却常被忽略。
