因HashSet存完整元素致内存超载，而布隆过滤器仅用位数组和哈希函数实现高效存在性判断（允许误判），适用于URL去重等场景。
为什么不用 HashSet 而要手写布隆过滤器
当数据量上亿、内存敏感且只需「判断是否存在」（允许少量误判）时，HashSet 的空间开销会成为瓶颈——它存的是完整元素，而布隆过滤器只用 k 个哈希位 + 一个位数组。典型场景：URL 去重、爬虫 URL 过滤、防缓存击穿的前置校验。
关键点在于：布隆过滤器不支持删除（除非用计数型变种），且无法枚举元素。别把它当 Dictionary 用，它只回答「这个值 很可能 存在过」。
BloomFilter 的核心参数怎么设才不翻车
三个参数决定精度和内存：位数组长度 m、哈希函数个数 k、预期插入元素数 n。设错会导致误判率飙升或浪费内存。
- 误判率公式：
p ≈ (1 − e^(−kn/m))^k，工程中常用近似：设m = -n * ln(p) / (ln(2)^2)，k = m / n * ln(2) - 例如：预计存 100 万条，接受 1% 误判率 →
m ≈ 9.6M bit ≈ 1.2MB，k = 7 - 实际编码时，
k取整后用 7 个独立哈希（推荐用 MurmurHash3 拆分种子，而非调用GetHashCode()多次——后者分布差、易碰撞）
如何避免线程不安全导致的位翻转错误
多个线程并发 Add() 同一个位索引时，若未同步，可能漏置位（虽不影响正确性），但 Contains() 在高并发下若读到未完全写完的位数组，可能返回假阴性（极少见）或假阳性（更常见）。这不是理论问题，是真实压测中出现过的现象。
实操建议：
- 用
ConcurrentDictionary包一层？不行——失去空间优势 - 用
Interlocked.Or()原子更新单个ulong（64 位），但需自己做位偏移计算 - 更稳妥：用
BitArray+lock细粒度锁（按位数组分段加锁，比如每 1024 位一个object锁） - 生产环境推荐直接用
Microsoft.Extensions.Caching.Memory配合自定义策略，或引入Google.Guava的 C# 移植版（如NetBloom），它们已处理好并发与扩容
为什么 String 直接喂给 GetHashCode() 会崩
.NET 的 string.GetHashCode() 是进程内随机种子，每次重启结果不同；跨 .NET 版本也可能变。布隆过滤器一旦序列化落盘或集群共享，哈希不一致就全废了。
必须用确定性哈希：
- 禁用：
"abc".GetHashCode() - 改用：
MurmurHash3.Hash(Encoding.UTF8.GetBytes("abc"), 0x12345678)（固定 seed） - 对
int等值类型，可用Unsafe.As转为字节再哈希，避免装箱(ref value) - 如果用
Span构造哈希输入，性能比byte[]高 20%+（尤其短字符串）
布隆过滤器最常被忽略的不是算法，而是哈希的确定性和位数组的持久化一致性——哪怕参数算得再准，哈希一漂移，整个结构就变成概率性错误而非概率性过滤。
