C++标准库无布隆过滤器，需自行实现；核心为位数组、多个独立哈希函数及统一插入/查询逻辑，推荐用std::vector手动位操作、MurmurHash3/xxHash，k取3~7，m设为2的幂以优化性能。
布隆过滤器在 C++ 里必须自己写，标准库没有 bloom_filter
标准 C++ 库至今没提供布隆过滤器实现，std::set 或 absl::flat_hash_set 都不能替代——它们存的是完整 key，而布隆过滤器只存哈希指纹，内存省一个数量级。如果你正为海量 URL 去重、爬虫判重或实时风控做预检，又卡在内存上，那得自己搭。
核心就三块：位数组 + 多个独立哈希函数 + 插入/查询逻辑。别用 std::vector<bool></bool> 当位数组——它不是真正的 byte 数组，operator[] 返回 proxy 对象，多线程下可能出竞态；改用 std::vector<uint8_t></uint8_t> 手动 bit 操作更稳。
- 哈希函数建议用
MurmurHash3或xxHash的 64 位变体，再对位数组长度取模，避免低质量哈希（比如std::hash对字符串连续 key 可能聚集） - 误判率由位数组长度
m和哈希函数个数k决定，公式是(1 - exp(-k * n / m))^k，其中n是预期插入元素数；通常取k = 0.7 * m / n最优 - 别把
k设太大（比如 >10），哈希计算开销会明显拖慢吞吐，实测k=3~7在多数场景已够用
插入和查询必须用同一套哈希逻辑，否则直接失效
这是最常踩的坑：插入时用 std::hash<:string></:string>，查询时换成了 boost::hash，或者哈希后没统一做 % m，结果查不到明明插过的 key，还以为数据丢了。
正确做法是把哈希封装成一个可复用的成员函数，比如 std::array<size_t k> hash_all(const std::string& key) const</size_t>，内部用同一个种子、同一种算法生成 K 个哈希值，并全部对 m 取模（注意：m 得是 2 的幂，否则取模慢；推荐用 m = 1 ，然后用位与 <code>& (m-1) 替代取模）。
立即学习“C++免费学习笔记（深入）”；
- 所有哈希值必须映射到位数组合法索引内，越界访问会导致未定义行为，Debug 版可用
assert(idx 拦住 - 插入时只置位，不检查原值；查询时只要有一个 bit 是 0，就确定不存在——这点不能反着来
- 别在查询时顺手“修复”缺失的 bit（比如自动补插），布隆过滤器不允许假阴性，一修就破戒
多线程环境下 std::atomic 不够用，得加锁
std::vector<uint8_t></uint8_t> 本身不支持原子 bit 操作，std::atomic<uint8_t></uint8_t> 只能整字节读写，而布隆过滤器要改单个 bit。强行用 fetch_or 改字节会误翻其他 key 的 bit，导致误判率飙升。
稳妥方案是用 std::shared_mutex（C++17）或 pthread_rwlock_t 控制读写：插入必须写锁，查询可以并发读锁。如果写入极少（比如初始化后只读）、查询极多，这个开销可接受；若写入频繁，就得考虑分片——把大位数组拆成 N 段，每段配独立锁，哈希时先 key % N 定片，降低锁争用。
- 别用
std::mutex包整个操作——读多写少时太伤并发度 - 分片数
N别设太小（64），实测 16~32 片在 16 核机器上平衡较好 - 分片后，每个分片的位数组长度要按总容量 /
N重新算，误判率公式里的m是单片长度，不是总长
删除操作不存在，别硬加 remove()
标准布隆过滤器不支持删除。网上有些“计数型布隆过滤器”（Counting Bloom Filter）用 uint8_t 计数代替 bit，但会吃更多内存（至少 4 倍），且计数溢出、减过头都会污染结果。除非你明确需要删除，且能承受内存翻倍+误判率上升，否则别碰。
真实业务中，与其折腾删除，不如换思路：定期重建过滤器（比如按小时滚动），或用二级结构兜底——布隆说“可能存在”，再查一次 std::unordered_set 确认；这样既保持布隆的内存优势，又规避了不可删的硬伤。
- 硬加
remove()并清零对应 bit，等于把其他共享该 bit 的 key 也“删掉”了，后续查它们全返回 false - 如果业务真强依赖删除，直接换
roaring bitmap或CRoaring，它们支持高效增删，且压缩比仍优于普通 set - 哪怕只是想“逻辑删除”，也别改布隆本体——在外部维护一个
std::unordered_set<:string></:string>存黑名单，查完布隆再过一遍黑名单
布隆过滤器的边界很清晰：它是个概率型存在性检查工具，不是通用集合。越想让它干更多事，越容易掉进内存、线程、一致性连环坑里。
