Lucene.NET 是 C# 中高性能全文搜索最成熟方案，但需手动配置中文分词器、正确管理 IndexWriter 创建模式、避免 MultiFieldQueryParser 解析异常，并显式 Close IndexSearcher。
Lucene.NET 是 C# 中实现高性能全文搜索最成熟、可控性最强的本地方案，但它不是开箱即用的“搜索引擎”，而是一套索引+查询 API。直接上 SearchClient.Search("xxx") 这类封装库（如 LiteDB 内置搜索）往往掩盖关键细节，导致线上查不到结果、中文分词失效、内存暴涨等问题。
为什么 StandardAnalyzer 对中文基本无效
StandardAnalyzer 默认按 Unicode 字母/数字边界切词，对连续中文文本（如“人工智能发展迅速”）会整个当做一个 token，无法匹配“智能”或“发展”。
这不是 bug，是设计使然——它面向英文等空格分隔语言。
必须换用支持中文分词的 Analyzer：
-
Lucene.Net.Analysis.Cn.Standard.StandardAnalyzer（需额外 NuGet 包Lucene.Net.Analysis.Cn） - 或更现代的选择：
Lucene.Net.Analysis.Stempel.StempelAnalyzer（波兰语词干，但对简体中文单字切分较稳定） - 自定义 Analyzer：继承
Analyzer，用ChineseTokenizer+StopFilter组合（注意：.NET 5+ 中部分老 tokenizer 已弃用）
示例：创建中文友好索引写入器
var analyzer = new StandardAnalyzer(LuceneVersion.LUCENE_48);
using var writer = new IndexWriter("index", analyzer, IndexWriter.MaxFieldLength.UNLIMITED);
若未显式指定 LuceneVersion，StandardAnalyzer 可能退化为旧版行为，导致分词逻辑不一致。
IndexWriter 构造时第三个参数 false 的陷阱
IndexWriter 构造函数第三个参数是 create（bool），控制是否清空已有索引目录。
新手常误写成 false 并反复调用 AddDocument，结果是每次启动都追加新 segment，索引体积膨胀、查询变慢、Optimize() 失效。
- 首次建索引：用
true，确保干净起步 - 增量更新：用
false，但必须配合UpdateDocument或先DeleteDocuments再AddDocument - 绝对避免在生产环境循环中无条件 new IndexWriter(..., false) —— 它不会自动合并旧 segment
正确增量写法片段：
var writer = new IndexWriter("index", analyzer, false);
writer.DeleteDocuments(new Term("id", "123"));
writer.AddDocument(doc);
writer.Commit(); // 不要只靠 Close()，显式 Commit 保证可见性
MultiFieldQueryParser.Parse() 报错 “Cannot parse 'xxx'” 的真实原因
这个异常几乎总是源于两处之一：一是传入的关键词含非法字符（如 AND、OR、+、-、括号），而 MultiFieldQueryParser 默认启用布尔语法解析；
二是字段名数组与实际 Document 中 Field 名不一致（大小写敏感！"Title" ≠ "title"）。
- 安全做法：对用户输入先做
QueryParser.Escape(keyword) - 调试时打印
parser.ToString()看生成的 Query 结构 - 字段名务必与
document.Add(new Field("content", ...))中第一个参数完全一致
不要依赖 try-catch 吞掉 Parse 异常——它意味着查询根本没发出去。
IndexSearcher 必须手动 Close，且不能跨线程复用
IndexSearcher 持有对索引文件的只读句柄和内存映射，.NET GC 不会自动释放底层资源。
常见错误：把它声明为 static 单例，在高并发下出现“文件被占用”或内存泄漏。
- 推荐模式：每次查询 new IndexSearcher(...) → 执行 Search →
searcher.Close() - 若需复用，用
DirectoryReader.Open()获取 reader，再传给new IndexSearcher(reader)，reader 可缓存，但 searcher 仍应短生命周期 - 使用
using无法保证 Close（因 IndexSearcher 未实现 IDisposable），必须显式调用
漏掉 Close() 后最直接的表现：索引目录被锁死，后续 IndexWriter 无法获取写锁，add 操作卡住或抛 IOException。
全文搜索真正难的不是写几行 AddDocument 和 Search，而是分词器选型与验证、索引生命周期管理、查询语法容错、以及资源释放时机——这些点在线上环境出问题时，日志里往往只显示“查不到”或“超时”，没有堆栈可循。
