std::vector 不适合作为高性能位图去重容器，因其 operator[] 返回临时 proxy 对象，不支持取地址、SIMD 加载、原子操作，且编译器难内联，导致 set/test 生成多条指令而非单条 bts/bt；预分配应使用 (max_val + 63) >> 6 避免除法开销。
直接用 std::vector<bool></bool> 做海量去重，性能会比手写位操作慢 2–3 倍，且无法做 SIMD 加速、原子操作或内存映射；它不是“位容器”，而是带代理语义的特化类，工程上应弃用。
为什么 std::vector<bool></bool> 不能用于高性能位图去重
它底层按位存储，但 operator[] 返回的是临时 std::vector<bool>::reference</bool>，不支持取地址（&bitmap[i] 编译失败）、无法传给 memset 或 AVX 指令、迭代器解引用行为异常；更关键的是——编译器难内联，热点路径中每次 set() 或 test() 都会生成多条指令，而非单条 bts/bt 汇编。
- 常见错误现象：
bitmap.data()编译报错；想用_mm256_load_si256扫描连续空块却因内存不可见而失败 - 值域为 0～10⁹ 时，
std::vector<bool>(1000000000)</bool>看似省空间，实测吞吐反而低于std::unordered_set - 多线程写入时，无法对单个 bit 做原子清零（
fetch_and(~mask)不是原子读-改-写闭环）
用 std::vector<uint64_t></uint64_t> 手动管理位图的实操要点
每个 uint64_t 存 64 个标志，内存连续、可随机访问、支持指针运算和原子操作，是生产环境首选。
- 索引计算必须用位运算：
word_idx = i >> 6和bit_idx = i & 0x3F，避免除法指令开销 - 预分配大小：`(max_val + 63) >> 6`，别用 `(max_val / 64) + 1`（当
max_val == 63时会少一单位） - 设位：
bits[word_idx] |= (1ULL ；查位：<code>(bits[word_idx] & (1ULL - 若数据非从 0 开始（如全是 1000000～2000000 的 ID），先整体减去 min 再映射，否则前导零浪费严重
如何跳过空块加速稀疏扫描（AVX2 实战）
当数据稀疏（比如 10 亿 ID 实际只覆盖 5000 万个不同值），连续检查全零区间是最大瓶颈；AVX2 可单指令判断 256 位是否全零，但要求严格对齐和类型转换。
立即学习“C++免费学习笔记（深入）”；
- 内存必须 32 字节对齐：
alignas(32) std::vector<uint8_t> bitmap;</uint8_t>，否则_mm256_load_si256触发 #GP 异常 - 跳空逻辑：将
uint8_t*指针reinterpret_cast<__m256i>(ptr)</__m256i>，再调_mm256_testc_si256(v, _mm256_setzero_si256()) - 返回非零表示该 32 字节块全零，可直接跳过；注意这只适用于“扫描找首个非零位”场景，不替代单点
test() - 未对齐或跨块访问时，退回到字节级循环，避免越界
多线程写入时原子操作的边界与陷阱
std::atomic<uint64_t></uint64_t> 可安全用于多线程 set()，但仅限“置位”；一旦需要 reset() 或引用计数，就不再安全。
- 两个线程同时对同一
uint64_t中不同 bit 调用fetch_or(mask)是安全的 - 但
fetch_and(~mask)清零某 bit 时，中间存在读-改-写窗口：线程 A 读出旧值、线程 B 同时置另一 bit、A 写回时覆盖 B 的修改 - 正确做法：若需清零，改用分片锁（per-word
std::shared_mutex）；或彻底放弃单 bit 清零，改用引用计数独立数组 - 所有原子操作必须配合
__builtin_expect提示分支预测（如if (__builtin_expect(existed, 0))），否则低存在率下分支失败率飙升
真正卡住性能的从来不是位运算本身，而是缓存行失效和分支预测失败；哪怕用了 AVX2，如果 ID 分布跨度远超 L3 缓存（比如随机 64 位整数），大部分时间都在等内存。所以——先确认值域是否真的适合位图，再动手写 set()。
