go-elasticsearch 多条件组合查询必须用 bool 查询，官方 v8+ 已移除 and/or 类型；需用 map[string]interface{} 逐层构造 must/should/filter，每次查询新建 map 避免并发问题，并通过 json.marshal + bytes.newreader 正确设置 body；高亮字段须显式声明且 stored=true。
Go-Elasticsearch 多条件组合查询必须用 bool 查询，不是拼 JSON 字符串
很多人一开始想手动拼 {"query":{"and":[{"term":{...}},{"range":{...}}]}}，但 Go-Elasticsearch 官方客户端（v8+）已完全移除 and/or 查询类型，所有逻辑组合必须走 bool。直接写 JSON 容易漏字段、类型错、嵌套深导致 panic，而且无法利用 IDE 提示和编译检查。
正确做法是用官方提供的 esapi 构建器 + map[string]interface{} 或结构体组合。最稳妥的是用 map 逐层构造，兼顾可读性和灵活性：
query := map[string]interface{}{
"bool": map[string]interface{}{
"must": []interface{}{
map[string]interface{}{"term": map[string]interface{}{"status": "active"}},
map[string]interface{}{"range": map[string]interface{}{"created_at": map[string]interface{}{"gte": "2024-01-01"}}},
},
"should": []interface{}{
map[string]interface{}{"match": map[string]interface{}{"title": "go"}},
map[string]interface{}{"match": map[string]interface{}{"content": "elasticsearch"}},
},
"minimum_should_match": 1,
"filter": []interface{}{
map[string]interface{}{"term": map[string]interface{}{"tenant_id": tenantID}},
},
},
}
注意：must 是 AND 语义，should 是 OR（需配 minimum_should_match），filter 不参与相关度计算、性能更好——微服务中高频查询建议把权限、租户、状态等固定条件全放 filter。
微服务场景下避免 Query 泄露或误复用的常见坑
在 HTTP handler 或 RPC 方法里直接 new query map 并传给 es.Search() 看似简单，但容易出问题：
-
map是引用类型，如果多个 goroutine 同时修改同一 query map（比如并发加must子句），会 panic 或结果错乱 - 没清空
should列表就复用 query 变量，导致上一次查询的条件残留 - 把用户输入未校验直接塞进
term或match，引发illegal_argument_exception
实操建议：
— 每次查询都新建 map[string]interface{}，不要复用变量
— 对用户可控字段（如搜索关键词、状态枚举）做白名单校验，非法值直接返回 400
— 租户 ID、服务版本号等内部字段用 filter 固定注入，不依赖前端传入
— 如果条件动态拼接复杂，封装成函数，例如：addTenantFilter(query, tenantID)，内部 deep-copy 或重建子结构
esapi.SearchRequest 的 Body 必须是 io.Reader，别用 bytes.Buffer 直接塞 map
常见错误：把 query map 直接赋给 req.Body = bytes.NewBuffer(...)，但没序列化成 JSON；或者用了 json.Marshal 却忘了 bytes.NewReader 包一层。结果要么 400（empty body），要么 406（invalid JSON），日志里只显示 "request body is required"，根本看不出哪错了。
Elasticsearch 9.4.1 Linux 版本现已开放下载，这是官方最新发布的分布式搜索与分析引擎。Linux 版本全面支持 x86_64 与 aarch64 架构，提供 .tar.gz、.deb 及 .rpm 多种安装包格式，可灵活适配 Ubuntu、CentOS、Debian 等主流发行版。该版本延续了 9.4 系列的核心特性，包括原生 Prometheus 支持、正式版 Elast
正确写法：
body, _ := json.Marshal(query) // 错误处理省略，实际要 check err
resp, err := es.Search(
es.Search.WithIndex("orders"),
es.Search.WithBody(bytes.NewReader(body)),
es.Search.WithContext(ctx),
)
注意点：
— WithBody 接收 io.Reader，不是 []byte 或 string
— json.Marshal 后必须用 bytes.NewReader 转成 reader，不能直接传 body
— 微服务中建议加个 helper 函数统一处理：func buildSearchBody(q map[string]interface{}) io.Reader，避免重复写 marshal + reader
聚合查询与高亮同时存在时，highlight 字段必须显式声明，且不能含 script_fields
微服务常需要查出匹配文档 + 高亮关键词 + 统计分类数量。但 highlight 和 aggs 共存时，容易忽略两个限制：
— highlight 默认只对 stored 字段生效，如果字段 mapping 设了 "store": false（默认），高亮会返回空数组，但查询本身成功，无报错
— highlight 不能作用于 script_fields 输出的字段，否则整个请求失败，报错："highlighter requires field to be stored"
解决方式：
— 在 index mapping 中对需高亮字段显式设 "store": true，例如：title、content
— highlight 配置必须用 fields 显式列出，不能靠 require_field_match: false 自动推导
— 聚合字段（如 terms on category）和高亮字段（如 title）分开定义，别混在同一个 script_fields 里
示例片段：
"highlight": {
"fields": {
"title": {},
"content": {"fragment_size": 150}
}
}
微服务里多条件组合查 ElasticSearch，真正麻烦的不是语法，而是 query 生命周期管理、租户隔离粒度、以及高亮/聚合/分页三者交叠时的隐性约束。这些地方不提前踩一遍，上线后查不出数据却没报错，才最耗时间。
