不能手写布隆过滤器，必须用 github.com/yourbasic/bloom——它自动解决哈希种子一致性、位数组字节对齐、并发写入安全；手写极易因种子未固定、位数组越界、多goroutine竞态写同一byte导致误判率飙升或崩溃。
别手写，直接用 github.com/yourbasic/bloom —— 它自动处理哈希一致性、位数组对齐、并发写入安全，而你自己实现的 NewBloomFilter 极大概率会在压测时误判率翻倍甚至越界崩溃。
为什么不能用自己写的 NewBloomFilter 函数
手写布隆过滤器看似只是几行位运算，但三个底层细节一错就全崩：
-
hash/fnv实例没固定种子，Add和Test用不同实例 → 同一个 key 算出不同位置，Test永远返回false - 位数组长度没对齐到字节边界（比如申请了 1007 bit），
bitset[i]访问时越界或漏掉最后几个 bit - 多个 goroutine 并发调
Add，同时对同一 byte 的不同 bit 执行|= 1→ 非原子操作导致某次置位被覆盖，该位永远为 0
bloom.New(n, p) 两个参数怎么填才不翻车
这两个值不是预估，而是系统生命周期内必须扛住的硬约束：
-
n是你「最多会插入多少个唯一项」，不是当前量。爬虫每天新增 500 万 URL，要撑 3 天，n至少填20_000_000；填小了，后期误判率会指数飙升 -
p是你「能接受的误判率」，比如0.001表示千分之一。别盲目设1e-6：从0.01→0.001，内存约翻倍；再降到0.0001，内存又翻倍，且初始化更慢 - 典型参考：
bloom.New(10_000_000, 0.01)（爬虫去重）、bloom.New(10_000_000, 0.001)（风控拦截）、bloom.New(1000, 0.0001)（设备白名单）
并发 Add 必须加锁，但 Test 可以完全无锁
bloom.Filter 底层是 []byte，读操作天然安全 —— 单字节读取在 Go 中是原子的；但写操作不是：
- 多个 goroutine 同时
Add同一个 key，可能同时算出位置1234，都执行bits[1234/8] |= 1→ 其中一次被覆盖，该位实际没置上 - 正确做法：包一层
sync.RWMutex，Add用Lock()，Test用RUnlock()（只读不阻塞） - 别用
sync.Mutex全局锁 ——Test是高频操作，没必要串行
Test 返回 true 后，下一步永远是查真实存储
这是最容易被跳过的逻辑责任，也是线上事故最高发点：
-
Test只回答「可能存在」或「一定不存在」，它不存原始数据，也不提供精确判断 - 缓存穿透防护链路必须是：
filter.Test(key) == false→ 直接放行；== true→ 查 Redis → 存在则返回，不存在则回源 DB 并写入 Redis - 风控场景里，
Test为true就直接拦截请求，结果把新用户当成老用户拒掉 —— 这不是布隆错了，是你漏了兜底
真正难的不是写对位运算，而是初始 n 和 p 填准、哈希输入稳定、并发写受控、二次校验不跳过 —— 这四点漏掉任何一点，布隆过滤器就会从加速器变成事故源。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
