kratos 不内置 elasticsearch 支持，需手动集成 elasticsearch-py 并自行管理客户端生命周期；其 data 层仅为示例，缺乏连接池对齐、重试、认证、多索引等生产级能力，且 mapping 和查询须解耦于业务逻辑外独立维护。
Kratos 框架本身不内置 Elasticsearch 支持，必须手动集成 elasticsearch-py 或 elasticsearch-dsl，且需绕过 Kratos 的默认 DI 机制做显式客户端管理——否则容易在服务启停、连接复用、健康检查环节出问题。
为什么不能直接用 Kratos 的 data 层封装 ES？
Kratos 的 data 包（如 data/elasticsearch）只是示例代码，不提供生产级 ES 客户端管理。它缺失关键能力：
- 连接池生命周期与 Kratos
App启停未对齐，Close()可能被忽略，导致 fd 泄露 - 无重试策略、超时控制、节点故障转移逻辑，
ConnectionError会直接抛到 handler 层 - 不支持多索引路由、
search_after分页、highlight响应解析等高频需求 - 硬编码了
http://localhost:9200，无法适配云环境或 Elastic Cloud 的 API Key 认证
怎么初始化一个可管理的 ES 客户端？
别依赖 Kratos 的 data.NewElasticsearch。直接用 elasticsearch-py 构建，并注入到 Kratos 的 Container 中，但要自己管好关闭逻辑：
- 用
elasticsearch.Elasticsearch初始化，传入hosts、basic_auth（ES 8.x 必须）、request_timeout和max_retries - 禁用
verify_certs=False（开发可临时开，生产必须关）；若用自签名证书，走ca_certs而非跳过校验 - 在
App的BeforeStart钩子里调用client.info()做连通性探测，失败则 panic - 在
App的AfterStop钩子里显式调用client.close()，否则连接不会释放 - 不要把 client 当成单例全局变量，必须通过 Kratos
di注入，确保测试时可 mock
示例片段（Python 风格伪代码，实际用 Go）：
esClient, err := elasticsearch.NewClient(elasticsearch.Config{
Addresses: []string{"https://es.example.com:9200"},
Username: "elastic",
Password: os.Getenv("ES_PASSWORD"),
Transport: &http.Transport{...}, // 自定义超时和 KeepAlive
})
if err != nil {
panic(err)
}
// 注入 Container
container.Register(func() *elasticsearch.Client { return esClient })
mapping 和索引怎么跟 Kratos 的业务逻辑解耦？
ES 的 mapping 是强 schema，不能靠 Kratos 的 service 层动态生成。必须提前固化：
- 把
PUT /my_index请求写成独立脚本（用curl或 Python），上线前执行，禁止在 Go 代码里用client.Indices.Create自动建索引 - 字符串字段严格区分：
"title": {"type": "text", "analyzer": "ik_smart"}用于检索，"status": {"type": "keyword"}用于过滤 - 日期字段必须显式声明
"published_at": {"type": "date", "format": "strict_date_optional_time||epoch_millis"}，否则range查询失效 - 在 Kratos 的
internal/biz层只处理文档结构映射（Go struct → JSON），不做任何 mapping 操作 - 用
dynamic: strict关闭自动映射，避免脏数据导致索引污染
查询逻辑怎么嵌入 Kratos 的 UseCase？
别在 internal/service 里拼 JSON 字符串。用 elasticsearch-dsl 构建 query，再转成 dict 交给 elasticsearch-py 执行：
- 定义
SearchRequest结构体，含Keyword、From、Size、Filters等字段，由 HTTP handler 解析后传入 UseCase - UseCase 内部用
Q('multi_match', query=kw, fields=['title^3', 'content'])构造主查询，再套Q('term', status='published')做过滤 - 高亮必须显式加
highlight={'fields': {'title': {}, 'content': {}}}，ES 不会自动高亮所有 text 字段 - 响应解析时，从
res['hits']['hits']提取_source和highlight，组装成业务 DTO 返回 - 错误统一转成 Kratos 的
errors.BadRequest或errors.InternalServer，不暴露 ES 原始错误信息（如index_not_found_exception）
最关键的细节：ES 查询不是事务操作，bulk 写入失败不会回滚数据库变更。必须在业务层做最终一致性补偿，比如监听 MySQL binlog 同步更新 ES，而非在 Kratos 事务里直写 ES。
