elasticsearch在c#中主流集成方式有4种：官方elastic.clients.elasticsearch（es 8.x+推荐，强类型弱、需手动管映射）、nest（7/8.x通用，强类型支持好但版本必须严格对齐）、elasticsearch.net（底层裸调，适合调试定制）及手写httpclient（轻量临时用）。
Elasticsearch 在 C# 中的集成方式，不是“随便选一个就行”，而是得看你的 Elasticsearch 服务版本、项目 .NET 版本、以及是否需要强类型映射或细粒度控制。目前真正可用且主流的只有 4 种组合，但其中两种已不推荐用于新项目。
用 Elastic.Clients.Elasticsearch（官方推荐，ES 8.x+）
这是 Elastic 官方自 8.0 起主推的新一代 .NET 客户端，完全重构，基于源生 HTTP 客户端，不依赖 Newtonsoft.Json，默认使用 System.Text.Json。
- 只兼容
Elasticsearch 8.x及以上（不向下兼容 7.x） - 必须配置 BasicAuth 或 API Key（ES 8.x 默认启用安全认证）：
.Authentication(new BasicAuthentication("elastic", "password")) - 连接写法更简洁：
var client = new ElasticsearchClient(new Uri("https://localhost:9200"), new BasicAuthentication(...)) - 不支持自动索引映射（如
[Keyword]特性），字段类型需在索引模板或PutIndexTemplate中显式定义
用 NEST（稳定成熟，ES 7.x / 8.x 均可）
NEST 是长期维护的高层 DSL 客户端，适合需要强类型建模、复杂查询构建、或从旧项目迁移的场景。
- 版本必须严格对齐服务端主版本：ES
8.12.0→ 必须用NEST 8.12.0，否则Invalid NEST response built from a unsuccessful low level call类错误高频出现 - 支持
[Text]、[Keyword]、[Date]等特性控制字段映射，但仅在首次创建索引时生效（后续改 mapping 需重建索引） - 连接时若漏掉
.BasicAuthentication()（ES 8.x）或.CertificateAuthentication()（启用了 TLS 的集群），会直接报Unauthorized (401)且无明确提示 - 默认不启用连接池；生产环境务必用
new SniffingConnectionPool(nodes)或至少new SingleNodeConnectionPool(node)
用 Elasticsearch.Net（底层裸调，调试/定制专用）
这是 NEST 的底层通信层，暴露原始请求/响应对象，适合封装自有 SDK、做协议级调试或绕过高层抽象限制。
- 所有请求需手动构造
PostData和 URL 路径，例如：client.LowLevel.Search<stringresponse>("my-index", PostData.Serializable(new { query = new { match_all = new {} } }))</stringresponse> - 不处理序列化策略自动切换，
System.Text.Json和Newtonsoft.Json需自行注入IElasticsearchSerializer - 没有内置重试、熔断、超时策略，这些都得自己补全
- 常见于排查
NEST报错时对比原始请求体，或实现 ES 不支持的实验性 API（如某些_plugins接口）
手写 HttpClient + JSON（轻量/临时/教学用）
不引入任何客户端库，纯 HttpClient 发送 JSON 请求，适合 PoC、脚本化操作或极简嵌入场景。
- 必须手动拼接完整 URL：
POST http://localhost:9200/my-index/_doc/1，注意路径大小写和尾部斜杠 - ES 8.x 必须带
Authorization: Basic ...请求头，Base64 编码"elastic:password"；漏掉就401 - 响应体是原始 JSON 字符串，解析靠
JsonSerializer.Deserialize<t>()</t>或JObject.Parse()，无类型安全 - 容易忽略
Content-Type: application/json头，导致406 Not Acceptable错误
实际项目里，Elastic.Clients.Elasticsearch 和 NEST 是唯二值得认真考虑的选项。前者更现代但牺牲了部分开发便利性；后者更“懂你”，但版本锁死风险高——尤其当团队同时维护多个 ES 集群（比如测试用 8.4、生产用 8.12）时，NEST 包版本稍不匹配，SearchRequest 构造就会静默失败。
