手写布隆过滤器考察的是约束下的合理取舍能力：哈希函数选择、位图结构（uint64数组比[]byte更省内存且位操作更快）、动态扩容等。核心是理解误判率、哈希分散性与位操作边界，并从最简版本迭代实现。
为什么不用现成的 bloomfilter 库而要手写
面试时手写布隆过滤器，考的不是你背没背过算法，而是能不能在约束下做合理取舍：比如哈希函数怎么选、位图用 []byte 还是 uint64 数组、是否支持动态扩容。很多候选人一上来就抄 github.com/yourbasic/bloom，结果被问「如果要支持 1 亿个 key，内存超了怎么办」就卡住。
手写的关键在于控制变量——先实现最简可用版本（固定容量、双哈希），再逐步加特性。面试官真正想看的是你对「误判率」「哈希分散性」「位操作边界」这些点有没有真实踩过坑。
用 uint64 数组比 []byte 更省空间且更快
位图底层本质是 bit 级别操作。[]byte 虽然直观，但每次 set/get 都要算 index / 8 和 index % 8，还涉及掩码和移位；而 []uint64 可以直接定位到第 i/64 个元素，再用 1 做位运算，CPU 缓存更友好，实测吞吐高 15%~20%。
- 位图长度 =
(capacity + 63) / 64（向上取整到 uint64 个数） - 设位：用
bits[idx] |= 1 ，注意 <code>offset必须是 0~63，否则行为未定义 - 查位：用
(bits[idx] & (1 ，别漏括号，位运算优先级低 - 清空整个 filter：直接
bits = make([]uint64, size)，Go 会自动 zero-initialize
hash64 函数必须避免负数模运算
Go 的 int64 % n 在被除数为负时结果仍为负，直接用于位图索引会 panic 或越界。常见错误写法：h1 % m —— 如果 h1 是负的，结果可能是 -5，导致 bits[-5] 访问非法内存。
立即学习“go语言免费学习笔记（深入）”；
|Git删除了文件，但还会在Git 仓库历史中遗留。 - 想要从 Git 历史移除敏感信息（密码、密钥、token、私钥） - 想要删除意外提交的大文件 - 想要重写 Git 历史、移除特定文件的所有痕迹 - 提到 "force push"、"重写 commit 历史" - 需要从所有分支、所有 tag 中删除某个文件
正确做法统一转成非负余数：
func hashMod(h, m int64) int64 {
return (h % m + m) % m
}实际中建议用两个独立哈希：h1 = fnv64(key)，h2 = murmur3_64(key)，然后组合出 k 个位置：hash(i) = (h1 + i*h2) % m（i 从 0 到 k-1）。这样比用 3 个不同哈希函数更容易调试，也避免哈希间相关性太强。
误判率计算不能只看公式，得结合实际 key 分布
理论误判率 (1 - e^(-k * n / m))^k 成立前提是：哈希均匀、key 独立、m 足够大。但真实场景中，如果 key 是时间戳或递增 ID，哪怕哈希函数再好，h1 和 h2 也会呈现强线性相关，导致多个 key 扎堆在相邻几个 bucket，误判率飙升。
应对方法：
- key 进来前先做一次简单混淆，比如
binary.BigEndian.PutUint64(buf, id^0xdeadbeef) - 测试阶段用真实业务数据跑压测，而不是随机字符串——比如拿 10 万条订单号灌入，统计
MayContain()返回 true 但实际不存在的比例 - 预留一个
FalsePositiveRate() float64方法，内部用当前已 set 的 bit 数反推，比纯理论值更有参考性
手写布隆最难的不是逻辑，是意识到「哈希质量」和「数据特征」永远在打架。调参时别光盯着 k=3 或 k=5，先用 pprof 看看 Set() 里哪一行最热，大概率是哈希函数或位操作本身。
