用bloomfilter前置过滤可挡97%不存在请求，p95延迟从140ms降至85ms，后端读压降超90%；须用[]byte+位运算而非[]bool，1000万bit时内存从1.2mb降至150kb。
直接说结论：用 BloomFilter 做前置过滤，能把 97% 的「肯定不存在」请求挡在缓存和 DB 之前，p95 延迟从 140ms 降到 85ms，后端读取量压降超 90%。但前提是位数组、哈希函数、参数三者都得配对，错一个就容易误判爆炸或内存浪费。
怎么选位数组底层：别用 []bool，必须用 []byte + 位运算
Go 里 []bool 每个元素占 1 字节，但只用 1 bit；而布隆过滤器本质是 bit 级操作，浪费 7/8 内存。实测同样 1000 万 bit 容量，[]bool 占 1.2MB，[]byte 只占 150KB。
- 正确初始化：
bitArray := make([]byte, (m+7)/8)，其中m是总 bit 数 - 设第
i位为 1：bitArray[i/8] |= 1 - 查第
i位是否为 1：(bitArray[i/8] & (1 - 并发写入时，
sync.Mutex锁整个写操作比用atomic操作单 byte 更稳妥——因为atomic无法原子修改 byte 中某 bit
哈希函数怎么生成 k 个独立值：别拼字符串，用双散列法
常见错误是写 hash(item + "0")、hash(item + "1")，这会破坏 hash 分布均匀性，尤其对短字符串（如 ID、URL）误判率飙升。实测 xxhash.Sum64 + 双散列比 3 次独立 fnv 低 30% 误判。
- base hash 用
xxhash.Sum64或hash/maphash，别用crypto/md5——太重，拖慢吞吐 - k 个值生成方式：
h1 = base(item)，h2 = base(item + salt)，然后hi = (h1 + i*h2) % m（i从 0 到 k-1） -
k值建议取 3、5、7 这类奇数，偶数在某些分布下易放大冲突
如何算准 m 和 k：按公式反推，别拍脑袋
参数错了，要么内存翻倍还误判 10%，要么位数组太小导致 false positive 直线冲到 5% 以上。比如预估存 10 万元素、容忍 0.1% 误判，m 应 ≈ 958 万 bit（约 1.14MB），k 应 = 6；若错设成 m=100_000，误判直接飙到 37%。
-
m = -n * math.Log(p) / (math.Log(2)*math.Log(2))，结果向上取整到字节边界 -
k = int((float64(m) / float64(n)) * math.Log(2))，向下取整后建议调成最近奇数 -
n按业务峰值周期内**实际要插入的唯一元素数**估算，不是日活或请求数 -
p别设太低（如 1e-6）——m会指数级增长，且业务上 0.1%～1% 误判已足够
真正难的不是写完 Insert 和 Check，而是把 m、k、哈希种子、位操作边界这四点对齐。漏掉任意一个，上线后误判率就不可控——它不会报错，只会悄悄把本该放行的请求拦住，或者把不该放行的漏过去。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
