为什么直接用 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，必须再走一次文件或数据库的精确匹配。这点绕不开，也别想绕开。
