std::vector<bool>不能直接用作Bitmap去重容器，因其是特化实现、底层按位存储，导致迭代器解引用返回代理对象、不支持取地址、无data()接口、缺乏集合操作，且映射需严格满足非负、可穷举、无冲突前提。
Bitmap去重为什么不能直接用std::vector<bool></bool>
因为std::vector<bool></bool>是C++标准库的特化实现，底层按位存储但接口伪装成布尔容器，导致迭代器、取地址（&v[i]）行为不可靠，且不支持data()直接获取原始字节数组——这对需要手动位运算的Bitmap是致命缺陷。实际做海量整数去重时，你得自己控制每个bit的读写，比如对数字n，要精准定位到第n / 8字节、第n % 8位。
实操建议：
- 用
std::vector<uint8_t></uint8_t>或std::unique_ptr<uint8_t></uint8_t>分配连续内存，大小为(max_value + 7) / 8字节 - 设值：
bits[n >> 3] |= (1 - 查值：
(bits[n >> 3] & (1 - 注意：若数据含负数或超大值（如>4GB），需先映射到非负紧凑区间，否则内存爆炸
如何处理超出内存范围的海量整数（比如10亿个int）
单机Bitmap要求值域相对集中，比如0~10亿（约125MB内存）。如果原始数据是随机int（-2^31 ~ 2^31-1），直接建图要4GB+内存，不可行。这时候必须分治。
常见做法是「分桶+局部Bitmap」：
立即学习“C++免费学习笔记（深入）”；
- 按高K位哈希分桶，例如取
n >> 24作为桶号，共256个桶，每个桶负责处理对应高位段的数（如桶0管0~16777215） - 每个桶内用独立
std::vector<uint8_t></uint8_t>做Bitmap，大小由该桶实际数据范围决定，而非全局最大值 - 插入时先算桶号，再算桶内偏移：
local_n = n & 0xFFFFFF（保留低24位） - 优势：内存按需分配，避免稀疏值域浪费；缺点：需额外哈希表或数组存桶指针，且无法一次判断“全局是否存在”，得查所有相关桶
std::bitset能替代手写Bitmap吗？
不能用于海量场景。std::bitset<n></n>的N必须是编译期常量，无法根据运行时数据动态确定大小。如果你的去重上限是10亿，就得写std::bitset——这会导致编译失败或栈溢出（它默认在栈上构造）。
更现实的选择：
- 用
boost::dynamic_bitset，支持运行时指定大小，底层用std::vector管理，接口接近std::bitset - 或坚持手写
std::vector<uint8_t></uint8_t>，完全可控，无第三方依赖，且可轻松扩展为持久化（如mmap文件-backed Bitmap） - 注意：所有Bitmap方案都假设输入是整数。如果是字符串去重，必须先做哈希（如
std::hash<:string>()</:string>）转为size_t，再考虑碰撞处理——这时Bitmap只能作快速布隆过滤器前置，不能保证100%准确
为什么查重比插入还容易出错？
插入只涉及一个位置写bit，而查重常被误写成“只要某一位是1就认为存在”，忽略了值域映射是否一致。典型错误是：分桶后查重时用了原始值n直接算偏移，没还原到桶内局部坐标。
调试关键点：
- 打印任意一个已插入数的桶号和局部偏移，验证计算逻辑：
bucket = n >> 24; local = n & 0xFFFFFF - 查重时务必复用同一套映射公式，别在插入用
n % BUCKET_SIZE，查重却用n & MASK - 用
valgrind --tool=memcheck跑小数据集，检查越界读（查重时bits[local >> 3]下标溢出最常见） - 如果去重后数量明显偏少，大概率是位操作掩码写反了，比如用了
1 这种镜像位序
真正难的不是算法本身，而是确保整数到bit位置的映射全程严格一致——差一位，整个Bitmap就废了。
