因为内存更省：布隆过滤器1亿条目仅需约12MB，而map[string]bool因哈希开销等可能占几GB；代价是存在误判且不支持删除，适用于允许少量误判的场景如缓存穿透防护。
为什么不用 map[string]bool 而要上布隆过滤器
因为内存。当你有上亿个字符串要查“是否见过”，map[string]bool 实际占的内存远超字符串本身——哈希表开销、指针、对齐填充全算上，轻松吃掉几 GB；而布隆过滤器用 bit 数组 + 多个哈希函数，1 亿条目可能只要 12MB，且查询是 O(k)（k 通常为 3–5）。
代价是：它只支持「可能存在」或「绝对不存在」，且不支持删除（标准版）。如果你的场景允许少量误判（比如缓存穿透防护、爬虫去重），那就值得。
- 典型误判率 1% 时，每个元素约需 9.6 bits；0.1% 需约 14.4 bits
- Go 标准库没内置，得自己写或用
github.com/yourbasic/bloom这类轻量库 - 别拿它存敏感判定逻辑（如权限校验），误判会导致“不该放行的放行了”
bloom.New 的三个参数怎么选才不翻车
初始化布隆过滤器时最常传错的是容量（cap）、误差率（fpRate）和哈希函数数（k）。多数库（如 yourbasic/bloom）只让你传前两个，k 自动算——但你得懂它怎么算的：
公式是 k = round(ln(2) * m / n)，其中 m 是位数组长度，n 是预估元素数。库会根据你给的 cap 和 fpRate 反推最优 m，再算出 k。所以重点在前两个参数：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
cap填的是「预计插入的最大元素数」，不是当前数量——填小了，误判率会指数级上升 -
fpRate别设成0.0001以为越小越好；它每降一档，内存几乎翻倍。0.01（1%）是常见平衡点 - 如果实际插入远超
cap，位数组会快速饱和，误判率奔着 50% 去，比随机还差
插入和查询时哈希函数必须一致，否则全失效
布隆过滤器的可靠性完全依赖「同一组哈希函数在插入和查询时输出完全相同」。Go 里容易踩的坑是：用了不同种子、不同哈希算法、甚至不同字节序处理。
例如，你自己实现哈希时用了 hash/fnv 但没固定种子，或者把 []byte 当字符串哈希（UTF-8 vs raw bytes 差异）；又或者用 sha256 截取前几位——这虽然安全但太慢，且截取方式不统一也会导致不一致。
- 推荐直接用成熟库的默认哈希（如
yourbasic/bloom用fnv+ 3 个不同种子） - 千万别手写哈希然后只在
Add里用，Test里换一个 - 如果数据是结构体，务必先序列化成稳定字节流（如
json.Marshal或gob.Encode），别直接哈希 struct 指针或字段顺序不保证的 map
并发写入必须加锁，但读可以无锁
bloom.Filter 本质是个 []byte，多个 goroutine 同时 Add 会竞态写同一位——结果就是位被意外清零或漏置，误判率失控。但 Test 是纯读，只要位数组不扩容（即不重新分配内存），就天然线程安全。
- 写操作（
Add、TestAndAdd）必须包一层sync.RWMutex或直接用sync.Mutex - 不要试图用
atomic.OrUint64替代锁——位操作跨字节时仍会出错，且 Go 的 atomic 不支持任意 bit 位置操作 - 如果写入集中、读多写少，可考虑分片布隆过滤器（sharded bloom），每个分片独立锁，但实现复杂度陡增
布隆过滤器真正的麻烦不在代码几行，而在容量预估和生命周期管理——它不像 map 那样能自动伸缩，一旦建好，cap 就定死了。线上跑着跑着发现插满了，只能重建+迁移，这时候没预留热替换机制，就会卡住。
