std::vector不能直接用于海量去重，因其是特化容器、底层按位存储但返回代理对象，不支持取地址、指针运算、data()接口及SIMD/原子操作，且迭代器行为异常、编译器难内联，导致性能比手写uint64_t位操作慢2–3倍。
Bitmap 为什么不能直接用 std::vector<bool></bool> 做海量去重
因为 std::vector<bool></bool> 是特化容器，底层按位存储但接口伪装成布尔数组，导致无法直接取地址、不支持指针算术、迭代器行为异常——在需要高频位操作（如批量置位、位扫描）的海量去重场景下，性能不可控，且难以对接 CPU 指令（如 _mm_popcnt_u64）或内存映射优化。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 手动管理
uint64_t*或unsigned char*内存块，按字长对齐分配，避免编译器插入填充或隐式转换 - 数据范围已知时（如 0~10⁹），优先用
size_t n_bits = max_val + 1计算桶数，再向上对齐到 64 的倍数 - 别用
new bool[n]—— 它是字节粒度，空间浪费 8 倍，且无位操作原语
如何安全计算 bit 位置并避免越界访问
关键不是“x / 64”和“x % 64”，而是整除与余数必须严格匹配平台字长，且所有索引必须做边界检查——尤其当输入含负数或超限值时，std::vector 不会帮你拦住，越界写入会静默破坏相邻内存。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 定义宏：
#define WORD_OFFSET(x) ((x) >> 6)和#define BIT_OFFSET(x) ((x) & 63)，位运算比除法快，且编译器能更好优化 - 构造 Bitmap 时传入合法上限
max_val，内部用words = (max_val >> 6) + 1分配，而非依赖用户传入 size - 所有
set()/test()前加if (x > max_val) return false;，不要指望调用方校验
多线程插入时要不要加锁？替代方案是什么
如果只是单机离线去重（如日志 ID 去重），完全可避免锁：先分片（如按 ID 哈希模 N），每线程独占一块 Bitmap 子区域，最后用位或合并；若必须全局唯一且并发高，std::atomic<uint64_t></uint64_t> 配合 CAS 循环置位比互斥锁快 3–5 倍。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 分片时用
hash(id) % n_shards，别用id % n_shards——ID 可能连续，导致负载倾斜 - 合并子 Bitmap 时，用
dst[i] |= src[i]批量操作，别逐 bit 调用set() - 若用原子操作，确保每次只操作一个
uint64_t字（即只置同一 word 内的 bit），否则需双重 CAS 或退化为锁
内存不足时 fallback 到磁盘 Bitmap 怎么不崩
直接 mmap 大文件看似简单，但 Linux 默认延迟分配（MAP_NORESERVE），首次写入可能触发 SIGBUS；Windows 上 CreateFileMapping 更易因磁盘满失败。真正可用的方案是预分配 + 稀疏文件 + 分块加载。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 创建文件后立即用
ftruncate()预设大小，再mmap()，避免运行时扩容失败 - 用
posix_fallocate()（Linux）或SetFileValidData()（Windows）保证物理空间，否则 mmap 后写入仍可能 ENOSPC - 不要整个 mmap——按需加载 1MB 分块，用
mmap(..., offset = chunk_i * 1024*1024)，减少 page fault 压力
Bitmap 的本质是空间换时间，但“空间”必须可控。最常被忽略的不是算法逻辑，而是分配对齐、索引截断、文件预占这三个硬性前提——漏掉任一，上线后都可能表现为随机崩溃或结果错误，且难以复现。
