cuckoo filter 因支持删除操作且空间效率不逊于 bloom filter，成为缓存淘汰、黑名单动态更新等场景的优选；虽存在极低误判率（可压至0.001%）及插入失败需扩容或踢出机制兜底，但其动态管理能力显著优于不支持删除的 bloom filter。
为什么不用 Bloom Filter 而选 Cuckoo Filter？
因为 BloomFilter 不支持删除，而 CuckooFilter 在保持相近空间开销的前提下，能做 Delete() —— 这对缓存淘汰、黑名单动态更新等场景很关键。但注意：它不保证 100% 准确，仍存在极小误判率（通常可压到 0.001%），且插入失败时需扩容或踢出策略兜底。
Go 中直接用哪个库？cuckoofilter 还是自己实现？
别自己重造轮子。社区成熟度最高的是 github.com/seiflotfy/cuckoofilter（已归档但仍在广泛使用），以及更活跃的 github.com/phil-mansfield/cuckoo。前者 API 更简洁，后者支持自定义哈希和并发安全封装。推荐起步用 cuckoofilter，示例：
cf := cuckoofilter.NewFilter(10000) // 容量约 1w 项
cf.Insert([]byte("user:123"))
found := cf.Lookup([]byte("user:123")) // true
cf.Delete([]byte("user:123"))
注意：Insert() 可能返回 false（插入失败），不是 panic，得主动判断；Lookup() 返回 bool，不区分“不存在”和“误判为存在”。
字符串 key 过长或含非 ASCII 字符怎么办？
CuckooFilter 内部只接受 []byte，且对长度敏感：太长会显著增加哈希冲突和踢出失败概率。常见做法：
- 对原始 key 做固定长度哈希（如
sha256.Sum256取前 8 字节），再传入Insert() - 避免直接传 JSON 或 URL 等长串；若必须保留语义，先用
xxhash.Sum64（快且分布好）生成指纹 - 中文、emoji 等 UTF-8 字符没问题，但得确保编码一致（不要混用
string和[]byte强转）
并发写入时为何 panic 或数据丢失？
原生 cuckoofilter 库不是 goroutine-safe 的。多个 goroutine 同时调用 Insert() 或 Delete() 会破坏内部 bucket 结构。解决方式只有两个：
- 用
sync.RWMutex包一层，读多写少时性能尚可 - 改用
github.com/phil-mansfield/cuckoo的cuckoo.ConcurrentFilter，它内部用分段锁，吞吐更高
别信“我只读不写就不用锁”——Lookup() 虽不改结构，但某些实现里会触发后台 rehash，仍有风险。
