Lucene.Net最轻量但需手动管理索引生命周期：须单例复用IndexWriter、显式设字段索引、用中文分词器、调Commit()提交，否则易出锁异常或搜不到数据。
用 Lucene.Net 做本地全文搜索最轻量，但得自己管索引生命周期
直接上手 Lucene.Net 是 C# 里最可控的全文搜索方案，尤其适合中小数据量、离线或内网场景。它不依赖外部服务，编译后就一个 DLL，但代价是：你得亲手创建 IndexWriter、管理 Directory（比如 FSDirectory.Open()）、定时重建或增量更新索引——没人帮你做这些。
常见错误是把索引目录放在临时路径或没加锁，导致 LockObtainFailedException；或者写完不调 writer.Commit()，搜不到新数据。
-
IndexWriter必须单例复用，不能每次搜索都 new 一个 - 字段要显式声明为
FieldType并设IsIndexed = true，否则建不出倒排索引 - 中文分词必须引入
Lucene.Net.Analysis.Cn或Lucene.Net.Analysis.Stempel，默认StandardAnalyzer对中文基本无效 - 查询时用
QueryParser.Parse()，别手拼TermQuery，否则不支持AND/OR和通配符
连 Elasticsearch 要走 HTTP，Nest 客户端比原生 HttpClient 少踩一半坑
如果数据量大、需要高可用或实时性，Elasticsearch 是更现实的选择。C# 端别自己封装 JSON 请求，直接用官方维护的 Nest 客户端——它自动处理序列化、连接池、重试和版本兼容（比如 ES 8.x 的 IndexName 默认小写，Nest 会帮你转）。
典型翻车点：ES 8 默认启用 HTTPS + Basic Auth，但很多人漏配 ConnectionSettings 里的 BasicAuthentication，结果卡在 401 Unauthorized；或者用错 SearchDescriptor 写法，把 Match 写成 Term，搜“北京”匹配不到“北京市”。
- 初始化
ElasticClient时传入new ConnectionSettings(new Uri("https://localhost:9200"))，别漏协议和端口 - 索引名必须全小写，ES 8+ 不接受大写字母，
Nest默认会转，但自定义名要手动检查 - 字段映射要用
[Text(Analyzer = "ik_smart")]这类特性标注，否则中文分词器不生效 - 批量写入用
client.Bulk()，别循环调Index()，否则吞吐掉 10 倍以上
数据库自带全文检索？SQL Server 的 CONTAINS 只能查表，且中文需额外配置
如果数据就在 SQL Server 里，又不想引入新组件，可以试试内置全文索引。但它不是“开箱即用”：必须先用 CREATE FULLTEXT CATALOG 建目录，再用 CREATE FULLTEXT INDEX 指定列，最后才能用 CONTAINS 或 FREETEXT 查询。
最大陷阱是中文语言设置——默认装的是英文语义词典，搜“手机”可能只匹配英文 “mobile”，必须在建索引时指定 LANGUAGE 2052（中文简体），否则分词和权重全乱。
- 建索引前确认数据库已启用全文服务：
SELECT SERVERPROPERTY('IsFullTextInstalled')返回 1 -
CONTAINS支持布尔逻辑（AND/OR），FREETEXT支持语义扩展，别混用 - 索引更新有延迟，默认 15 分钟，测试时加
ALTER FULLTEXT INDEX ON table_name SET CHANGE_TRACKING AUTO - WHERE 条件里不能直接写
CONTAINS(col, '关键词')，必须配合FROM子句，且表要有唯一非空索引
别在 Where 里写 Contains() 当全文搜——那是字符串匹配，不是倒排索引
很多新手把 EF Core 的 Where(x => x.Title.Contains("搜索词")) 当全文检索用，其实这只是 SQL 的 LIKE '%搜索词%'，数据一过万行就慢得没法忍，还无法支持相关性排序、同义词、模糊匹配。
它和真正全文搜索的区别在于：前者逐行扫描、无索引加速；后者靠预建的倒排索引定位文档 ID，再按 TF-IDF 或 BM25 算分排序。性能差两个数量级是常态。
- EF Core 的
Contains()在 SQL Server 上生成CHARINDEX或LIKE，MySQL 上是INSTR，都不走全文索引 - 即使数据库开了全文索引，EF Core 也不自动翻译成
CONTAINS，得用FromSqlRaw手写 - 想兼顾 ORM 和搜索，建议业务层拆开：用 EF 查主键列表，再用 Lucene/Elastic 搜 ID，最后用 EF
FindRange()批量取实体
实际选型时，Lucene.Net 的冷启动快但运维成本藏得深，Elasticsearch 配置多一步却省掉所有索引维护逻辑，而 SQL Server 全文索引看着省事，可一旦要跨库、要高亮、要拼音搜索，马上得切出去。这些边界条件，上线前就得想清楚。
