hashset内存占用大、gc压力高且不支持序列化复用；布隆过滤器用位数组压缩存在性判断，冷启动快、允许低误判率。.net中推荐naivebloomfilter，初始化需expecteditemcount和falsepositiverate，字符串须转utf8字节数组后添加，contains()返回true仅表示“可能存在”，false才确信不存在。
为什么直接用 HashSet<string></string> 不够快？
当文件内容条目达到百万级，且只做「是否存在」判断时，HashSet<string></string> 的内存占用会迅速膨胀（每个字符串对象含堆头、引用、字符数组），GC 压力大；更关键的是，它不支持序列化后复用——每次启动都要重载全部数据。布隆过滤器用固定大小的位数组 + 多个哈希函数，把「存在性」压缩到几十 MB 甚至几 MB，适合冷启动快、允许极低误判率的场景。
BloomFilter<t></t> 在 .NET 6+ 中怎么初始化？
.NET 官方没有内置布隆过滤器，但 Microsoft.Extensions.Caching.Memory 也不提供。推荐使用成熟第三方库：Wintellect.PowerCollections 已停更，当前最稳妥是 JetBrains.Annotations 不相关，实际应选 EasyNetQ.BloomFilter 或更轻量的 NaiveBloomFilter（纯内存、无依赖）。以 NaiveBloomFilter 为例：
dotnet add package NaiveBloomFilter
初始化需两个关键参数：预期元素数量 expectedItemCount 和可接受误判率 falsePositiveRate（如 0.01 表示 1%）。不要凭空拍数字：
- 若文件有 50 万行文本，设
expectedItemCount = 500000 - 误判率低于 0.001 会导致位数组过大，一般 0.01～0.03 足够；设为 0.02 时，内部自动计算出约 7.3 MB 内存占用
- 不要用
new BloomFilter<string>(...)</string>—— 它泛型约束要求T实现IConvertible，字符串不满足；应改用BloomFilter<byte></byte>或对字符串做Encoding.UTF8.GetBytes()后插入
如何把文件逐行内容喂给布隆过滤器？
不能直接 filter.Add(line)（line 是 string），必须先转字节数组。否则编译报错或运行时异常。正确流程：
- 打开文件用
StreamReader逐行读取，避免一次性加载全量到内存 - 每行调用
Encoding.UTF8.GetBytes(line)得到byte[]，再传给filter.Add() - 注意：行末换行符（
\r\n或\n）会影响哈希结果，建议统一用line.TrimEnd('\r', '\n')预处理 - 如果文件含 BOM，
StreamReader默认会剥离，无需额外处理；但若手动读取字节流，则必须跳过 BOM
示例关键片段：
var filter = new BloomFilter<byte[]>(500000, 0.02);
using var reader = new StreamReader("data.txt");
string line;
while ((line = reader.ReadLine()) != null)
{
var bytes = Encoding.UTF8.GetBytes(line.TrimEnd('\r', '\n'));
filter.Add(bytes);
}
判断某内容是否「可能存在于文件中」的坑在哪？
布隆过滤器只支持 Contains()，返回 bool，但这个 true 意味着「可能存在」，false 才是「绝对不存在」。常见误用：
- 把
filter.Contains(Encoding.UTF8.GetBytes(input)) == true当作「确认存在」，进而跳过后续精确查找 —— 这会漏数据，因为布隆过滤器不存原始值 - 对不同编码的输入重复计算字节数组（比如文件是 UTF-8，但查询用 GB2312 编码的 byte[]），必然返回
false，不是逻辑错，是编码错 - 多线程并发调用
Add()是非线程安全的；若需边读边建，必须加锁；而Contains()是线程安全的 - 序列化后下次启动反序列化，必须确保用的是同一版本库 ——
NaiveBloomFilterv1.2 和 v1.3 的位数组结构不兼容
真正落地时，布隆过滤器只是第一道门：查到 false 直接返回「不存在」；查到 true，必须再走一次文件或数据库的精确匹配。这点绕不开，也别想绕开。
