应直接使用成熟布隆过滤器库而非手写，因其已通过压测、并发安全且自动推导参数；手写易在哈希一致性、位数组边界对齐、并发写入等方面出错，导致误判率飙升或内存浪费。
为什么别手写 NewBloomFilter 而要直接用成熟库
Go 生态里已经有经过压测、并发安全、参数自动推导的布隆过滤器实现，比如 github.com/willf/bloom 或 github.com/phil-mansfield/bloom。自己从零写一个看似简单，但极易在哈希一致性、位数组边界、并发写入上翻车。
- 手写容易用错哈希：比如
hash/fnv不设固定种子，Add和Test用不同实例，导致永远查不到 - 位数组长度没对齐到字节边界，
bitset[i]访问越界或漏位 - 多个 goroutine 同时调用
Add，竞态修改同一个byte的不同 bit，结果该置 1 的没置上 → 误判率飙升 - 误判率公式
(1 - e^(-kn/m))^k看似简单，但实际初始化时得反解m和k，手动算错一两位，内存就差几倍
bloom.New(10_000_000, 0.001) 这两个参数到底怎么定
第一个是预估最大元素数 n，第二个是可接受的误判率 p（比如 0.001 表示千分之一）。它们不是拍脑袋填的，直接决定内存用量和可靠性。
-
n填小了：位数组不够用，后期误判率远超预期；填大了：浪费内存，但至少安全 -
p填太小（如1e-6）：m会指数级增长，1 亿条目可能从 12MB 涨到 200MB+ - 典型场景参考：爬虫去重 1000 万 URL，选
0.01（1%）就够；风控拦截需更严，用0.001；局域网设备白名单几百个，0.0001也绰绰有余 - 注意：
bloom.New内部会按最优k = round(ln(2) * m / n)自动选哈希个数，你不用管
并发 Add 时加锁不是“可选”，而是“必须”
bloom.Filter 底层是 []byte，多个 goroutine 同时 Add 同一个 key，可能同时对同一 byte 的不同 bit 执行 |= 1 —— 这个操作非原子，结果就是某次置位被覆盖，该位置永远为 0。
- 现象：明明
Add过的 key，Test返回false；或者误判率忽高忽低，压测时飘到 5% - 正确做法：包一层
sync.RWMutex，Add用Lock()，Test用RUnlock()（读可并发） - 不推荐用
sync.Mutex全局锁——Test是高频只读操作，没必要阻塞 - 如果真需要无锁写入，得换支持 CAS 的结构，比如布谷鸟过滤器（
cuckoo filter），但 Go 生态成熟度低得多
Test 返回 true 后，下一步永远是查真实存储
布隆过滤器只回答「可能存在」或「一定不存在」，它本身不存原始数据，也不提供精确判断能力。跳过二次校验等于默认接受误判。
- 缓存穿透防护场景：先
filter.Test(key)，false 就直接回源；true 则必须查 Redis 或 DB，确认存在才返回，否则仍要回源（避免把误判当真） - 爬虫去重：不能因为
Test(url)是 true 就跳过抓取，得查本地已抓 URL 表或持久化去重库 - 千万别在
Test为 true 时再Add一次——布隆过滤器不负责去重逻辑，那是业务层的事 - 序列化要稳定：传给
Add和Test的必须是同一字节流，json.Marshal比直接哈希 struct 安全，字段顺序、空字段处理都可控
最常被忽略的点是哈希函数的一致性——哪怕只改了一个哈希函数的种子，或把 []byte("abc") 和 string("abc") 当等价输入，整个过滤器就失效。布隆过滤器的脆弱性不在容量或速度，而在那几行哈希代码是否严格复用。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
