生产环境应直接使用 github.com/yourbasic/bloom 或 github.com/AndreasBriese/bbloom，避免手写位数组；前者轻量简洁，后者适合高吞吐场景；切勿用 map[string]struct{} 替代，内存开销相差百倍。
用哪个库？别自己手写位数组
生产环境直接用 github.com/yourbasic/bloom 或 github.com/AndreasBriese/bbloom，别从零实现——哈希一致性、内存对齐、并发安全这些坑早被踩平了。自己写 []bool 或 []byte + 手动位运算，容易在 Test() 和 Add() 用不同哈希逻辑，导致全失效。
-
yourbasic/bloom最轻量，API 简洁：New(cap, fpRate)直接生成，内部自动拉齐位数组长度为 2 的幂次，避免慢的%运算 -
bbloom支持更细粒度控制，比如指定哈希种子、预分配字节池，适合高吞吐场景 - 千万别用
map[string]struct{}替代——1 千万个 URL，它轻松吃掉 1.5GB+ 内存；而布隆过滤器只要约 12MB
初始化参数怎么设？误判率不是越小越好
调 bloom.New(10_000_000, 0.001) 时，0.001 是你愿意接受的误判率（千分之一），但每降一档（比如改成 0.0001），位数组大小几乎翻倍，内存和初始化耗时都明显上涨。
- 公式上，
m ≈ -n * ln(fp) / (ln(2)²)，n=10_000_000、fp=0.001→m≈1.44千万bit ≈ 1.75MB；若fp=0.0001，m直接跳到 ~2.3MB - 预估
n要留余量：如果爬虫每天新增 500 万 URL，计划撑 3 天，至少按n=20_000_000初始化，否则后期误判率会远超预期 - 一旦实际插入数明显超过
n，不要硬撑——重建过滤器并批量重放历史 key，否则误判率会指数级上升
并发写入必须加锁，但读可以无锁
bloom.Filter 底层是 []byte，多个 goroutine 同时调 Add() 会竞态写同一位，导致该位被意外清零或漏置，误判率失控。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 写操作（
Add）必须加sync.RWMutex或用sync.Pool配合单例 filter - 读操作（
Test）天然无锁——因为只读不写，且位运算是原子的（byte读取本身是原子的） - 如果读写都高频，考虑用
bbloom的WithPool()模式，复用哈希计算中间状态，减少 GC 压力
Test 返回 true 后必须二次校验，这是逻辑责任
filter.Test(key) 返回 true 只表示「很可能存在」，绝不能直接跳过后续 DB/Redis 查询——否则就把误判当成真实存在，丢数据。
立即学习“go语言免费学习笔记（深入）”；
- 典型链路是：
Test() → false就放行；Test() → true则查 Redis → 存在就返回，不存在再回源 DB 并写入 Redis - 常见错误：在风控场景里，
Test()为 true 就直接拦截请求，结果把新用户当成老用户拒掉——这不是布隆错了，是你没兜住逻辑 - 别在
Test()为 true 时顺手再Add()一次——布隆不负责去重，只负责快速过滤；重复 Add 不影响结果，但浪费 CPU
布隆过滤器最危险的地方不在实现，而在它“看起来像确定性判断”的错觉。只要记住：它永远只回答“可能有”或“肯定无”，而“可能有”之后那一步，得你亲手写清楚。
