为什么不用 HashSet<t></t>
而要手写布隆过滤器
当数据量上亿、内存敏感且只需「判断是否存在」（允许少量误判）时，
HashSet<t></t>的空间开销会成为瓶颈——它存的是完整元素，而布隆过滤器只用
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<string bool></string>包一层？不行——失去空间优势 用
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<int uint>(ref value)</int>转为字节再哈希，避免装箱 如果用
Span<byte></byte>构造哈希输入，性能比
byte[]高 20%+（尤其短字符串）
布隆过滤器最常被忽略的不是算法，而是哈希的确定性和位数组的持久化一致性——哪怕参数算得再准，哈希一漂移，整个结构就变成概率性错误而非概率性过滤。
