应直接使用 github.com/yourbasic/bloom 库，因其轻量无依赖、API 干净、自动优化位数组长度与哈希逻辑，且已修复哈希不一致、并发竞态、误判率失控等常见问题。
直接用 github.com/yourbasic/bloom，别手写
生产环境里，布隆过滤器不是练手项目，而是要扛住千万级 URL 去重、风控 ID 过滤这类真实流量的。自己用 []byte + 手动位运算写，90% 的坑早被踩平了：哈希不一致、内存未对齐、并发写竞态、误判率失控……全在成熟库里修好了。yourbasic/bloom 是目前最轻量、无依赖、API 最干净的选择，连 go mod tidy 都不带多余包。
-
New(cap, fpRate)一行初始化，内部自动把位数组长度拉齐为 2 的幂次，避开慢的%运算 - 它默认用 3 个 FNV 哈希（不同种子），
Add()和Test()复用同一套逻辑，不会因哈希不一致导致全失效 - 别碰
bbloom除非你真需要细粒度控制——比如指定哈希种子、复用字节池；日常场景它反而增加理解成本
bloom.New(10_000_000, 0.001) 这两个参数怎么填才不翻车
填错这里，后面所有操作都白搭。不是“大概估一下”，而是必须按系统生命周期最大压力来预估。
-
cap填的是「你未来最多会Add多少个唯一项」，不是当前数量。比如爬虫每天新增 500 万 URL，想撑 3 天，就得按n = 20_000_000初始化，否则后期误判率会指数上升 -
fpRate别盲目设成0.0001（万分之一）——每降一档，位数组大小几乎翻倍。从0.01降到0.001，内存从 ~1.2MB → ~1.75MB；再降到0.0001，直接跳到 ~2.3MB，且初始化更慢 - 公式上，位数
m ≈ -n * ln(fp) / (ln(2)²)，但你不用算——库会自动推导；你只管把cap和fpRate给准
并发写必须加锁，但 Test() 可以完全无锁
bloom.Filter 底层是 []byte，多个 goroutine 同时调 Add() 会竞态写同一位，导致该位被意外清零或漏置，误判率瞬间失控。但读操作天然安全——因为 Test() 只读不写，且单字节读取在 Go 中是原子的。
- 写操作（
Add）必须包一层sync.RWMutex或用sync.Pool管理单例 filter - 读操作（
Test）可放心并发调用，无需任何同步开销 - 如果读写都高频，考虑
bbloom.WithPool()模式，复用哈希中间状态，减少 GC 压力；但多数场景yourbasic/bloom+ 读写分离锁就足够
Test() 返回 true 后，必须二次校验
这是逻辑责任，不是布隆过滤器的缺陷。它只回答“很可能存在”，绝不能替代真实存储判断。一旦跳过校验，就把误判当成真实存在，数据就丢了。
立即学习“go语言免费学习笔记（深入）”；
-
Test(key) == false→ 可直接放行（100% 不存在） -
Test(key) == true→ 必须查 Redis / DB / 本地 map，确认真实存在后再走后续逻辑 - 典型链路：
Test() → false → 放行；Test() → true → 查 Redis → 存在则返回，不存在则回源 DB 并写入 Redis - 风控场景里，
Test()为true就直接拦截请求，结果把新用户当老用户拒掉——这不是布隆错了，是你没兜住逻辑
布隆过滤器最危险的不是误判率，而是人误以为它能代替精确判断。它只是一道极快的门禁，后面永远得跟一道真实的锁。
