布隆过滤器核心结构用std::vector最省空间，但需注意其位打包实现导致operator[]返回代理引用，不可取地址或用于需要bool*的函数。
布隆过滤器的核心结构用什么容器存？
用 std::vector<bool></bool> 最省空间，但得小心它的代理引用陷阱。它不是真正的 bool 数组，而是位打包实现，operator[] 返回的是 std::vector<bool>::reference</bool>，不能取地址、不能传给需要 bool* 的函数。
- 别写
&v[i]—— 编译不过，会报错cannot take the address of a bit-field - 哈希后要设置位，必须用
v[i] = true，不能用指针算术或memcpy操作底层内存 - 如果对性能极度敏感（比如每秒百万次查询），可考虑
std::vector<uint64_t></uint64_t>手动位运算，但实现复杂度陡增
三个哈希函数怎么写才不翻车？
C++ 没有内置多哈希支持，自己写容易撞哈希、分布不均。别用 std::hash<:string>()(s) % m</:string> 直接取模——不同哈希值模同一个数，冲突概率飙升。
- 推荐组合法：用一个基础哈希（如
std::hash）产出 64 位结果，再拆成 3 个独立哈希值：h1 = h, h2 = h * k1 + k2, h3 = h * k2 + k1，其中k1,k2是大质数（如 1000000007、1000000009） - 每个哈希值都要做
% m，但m必须是 2 的幂时才能用& (m-1)加速——这会暴露哈希低位缺陷，除非你确认哈希本身已充分混洗 - 字符串输入务必处理空值和长串：
std::hash对空串返回固定值，多个空串全映射到同一组位置，导致假阳性率失控
插入和查询的边界条件有哪些？
布隆过滤器一旦初始化，m（位数组长度）和 k（哈希个数）就不能变。但实际用的时候，很容易在构造时低估数据量，或者漏掉重置逻辑。
- 构造时
m太小 → 假阳性率指数级上升；经验公式：m ≈ -n * ln(p) / (ln(2)^2)，其中n是预期元素数，p是容忍假阳性率（如 0.01） - 没提供
clear()方法 → 多次复用对象时残留旧数据，查不到新插入项却返回true -
contains()返回true只表示“可能在”，永远不能用于删除判断；想支持删除就得换counting bloom filter，但那是另一套内存布局了
为什么 std::bitset 不适合做通用布隆过滤器？
std::bitset 大小必须编译期确定，而真实场景里 m 往往由运行时参数（比如配置文件里的 expected_items）决定。
立即学习“C++免费学习笔记（深入）”；
- 写
std::bitset看似省事，但无法适配不同数据规模，模块复用性归零 - 它不支持动态 resize，也没办法直接从文件 mmap 初始化位图
- 某些嵌入式环境禁用 STL 容器，
std::vector<bool></bool>可能被裁剪，这时得回退到裸uint8_t*+ 手动位操作
真正难的不是写出来，是让 m 和 k 在上线后还能根据实际流量微调，又不破坏已有数据一致性。这点几乎没人提，但线上扩缩容时最头疼。
