布隆过滤器比 map[string]struct{} 更省内存，适合千万级实时去重；它用固定位数组和多哈希实现约1%空间占用，允许误判但不漏判，仅支持存在性判断且不可删除；需按最大元素数和容忍误判率初始化，配合Redis等二次校验，并注意并发安全。
为什么不用 map[string]struct{} 而要上布隆过滤器
当数据量超过千万级，尤其是做实时去重（比如爬虫 URL 去重、风控请求 ID 过滤），map[string]struct{} 的内存开销会迅速失控——每个 key 至少占几十字节，1 亿个字符串轻松吃掉几 GB 内存。布隆过滤器用固定大小的位数组 + 多个哈希函数，把空间压缩到 1% 以内，代价是允许极小概率误判（false positive），但**绝不会漏判（false negative）**。
关键点：它只适合「存在性判断」，不能查具体值，也不能删除（标准实现）。如果你需要精确计数或反查，别硬套。
用 github.com/yourbasic/bloom 实现最小可行版本
第三方库比手撸更稳，github.com/yourbasic/bloom 是目前最轻量、无依赖、API 清晰的选择。它默认用 3 个哈希函数，支持自定义误差率和预估容量。
常见错误现象：bloom.New(1000000, 0.01) 看似设了 100 万容量和 1% 误差，但实际插入超量后误判率会指数上升；必须按**预期最大元素数**初始化，不能拍脑袋填。
立即学习“go语言免费学习笔记（深入）”；
- 初始化时，
n填你未来最多塞多少个唯一项（不是当前数量） -
p填可接受的误判率（如0.001表示千分之一），越小位数组越大 - 插入前无需检查是否已存在——布隆过滤器本身不提供
Contains后再Add的原子操作，业务层自己控制
filter := bloom.New(10_000_000, 0.001) // 预估 1000 万个 URL，容忍 0.1% 误判
filter.Add([]byte("https://example.com/path"))
if filter.Test([]byte("https://example.com/path")) {
// 可能存在（注意：只是可能，需二次确认）
}
误判后怎么安全地二次验证
布隆过滤器返回 true 只表示「很可能存在」，必须接一层真实存储校验，否则会丢数据。典型组合是：bloom filter → Redis SET / local map / DB 查询。
容易踩的坑：filter.Test(key) 返回 false 就直接放行，这没问题；但返回 true 时如果跳过后续校验，就会把本不存在的 key 当成已存在而丢弃——这是误判导致的漏处理，不是布隆本身的错，而是逻辑没兜住。
- 永远把
Test()结果当作「需要进一步确认」的信号，不是最终结论 - 校验存储建议用带 TTL 的 Redis
SETNX，避免并发写入冲突 - 不要在
Test()为true时直接写入布隆过滤器——它不负责去重，只负责快速拦截
性能和并发要注意的硬限制
github.com/yourbasic/bloom 的 Add 和 Test 方法**不是并发安全的**。多个 goroutine 同时调用会引发 panic 或数据损坏。
解决方案只有两个：加 sync.RWMutex，或者用 sync.Pool 每次分配独立 filter（适合短生命周期场景）。别信“读多写少就不用锁”——位数组的多个哈希位置写入是分散且非原子的，RWMutex 也得上写锁。
- 高并发下，单 filter + mutex 会成为瓶颈，此时考虑分片（shard）：按 key 哈希取模分到 N 个 filter，各自加锁
- 别用
unsafe或原子操作手动优化位翻转——该库底层已用uint64批量操作，再折腾收益极低还易出错 - GC 友好：filter 本身只含
[]byte，没有指针，不会拖慢 GC
真正难的是预估容量和误差率的平衡，填错一个参数，要么内存暴增，要么误判高到不可用——这没法靠测试发现，得靠上线前压测和线上采样统计。
