go用elastic客户端发聚合请求需手动构造aggs json结构，必须注意字段名、嵌套层级、.keyword后缀、类型断言安全、size与execution_hint优化及time_zone一致性。
Go 用 elastic 客户端发聚合请求，必须手动构造 aggs JSON 结构
Go 的官方 Elasticsearch 客户端（olivere/elastic）不提供像 Kibana 那样“点选式”的聚合 DSL 封装。你得自己拼 map[string]interface{} 或用结构体序列化成符合 ES 要求的 aggs 字段。这不是缺陷，是设计取舍——它把控制权完全交给你，也意味着写错一个 key 名或嵌套层级，ES 就直接返回 "Unknown key for a START_OBJECT in [aggs]"。
实操建议：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 先在 Kibana Dev Tools 里把聚合语句调通，再照着 JSON 搬到 Go 里，别凭记忆手写
- 用
json.MarshalIndent打印出最终请求体，和 Kibana 里的对比字段名、缩进、引号是否一致 - 注意：ES 的
terms聚合字段名必须带.keyword后缀（如果该字段是text类型），否则返回空桶——Go 里容易漏掉这个细节 - 避免用
interface{}嵌套太深，推荐定义小结构体（如TermsAgg、DateHistogramAgg），提升可读性和编译期检查
聚合结果解析时，response.Aggregations 是 map，不是结构体
olivere/elastic 把所有聚合结果塞进一个 map[string]*elastic.AggregationBucketKeyItems，没有自动反序列化成你定义的类型。你得手动从 map 里取键、断言类型、再取值。稍不注意就会 panic：panic: interface conversion: interface {} is nil, not *elastic.StringTermsBucket。
常见错误现象：
- 直接对
agg, ok := res.Aggregations.Terms("status_agg")的ok判断为真，但没检查agg.Buckets是否为空 - 用错类型断言，比如把
date_histogram当成terms解析 - 忽略嵌套聚合：子聚合结果藏在父 bucket 的
Aggregations字段里，不是顶层res.Aggregations
实操建议：
- 永远先判空：
if len(buckets) == 0，再遍历 - 用
elastic.NewStringTermsBucket或elastic.NewDateHistogramBucket显式转换，比类型断言更安全 - 嵌套聚合必须逐层展开：先取外层 bucket，再取其
Aggregations，再取内层聚合名
聚合性能差？检查 size 和 execution_hint
默认情况下，terms 聚合只返回前 10 个桶，但如果你设了 size: 1000，ES 会把所有匹配 term 加载进内存排序——数据量大时极易 OOM 或超时。更隐蔽的问题是：ES 默认用 map 方式执行聚合，而对高基数字段（比如用户 ID），execution_hint: "map" 效率极低；换成 "global_ordinals" 可提速数倍，但要求字段有 fielddata: true（默认关闭）。
实操建议：
- 生产环境不要设
size: 0或极大值；按需取，必要时加collect_mode: "breadth_first"控制内存使用 - 对
keyword字段做高频聚合，务必在 mapping 中开启fielddata: true，并确认该字段不是text+keyword子字段混用 - 用
elastic.NewTermsAggregation().ExecutionHint("global_ordinals")显式指定 hint，别依赖默认 - 聚合前加
filter减少文档集大小，比在聚合后用include/exclude更省资源
时间范围聚合用 date_histogram，但 Go 里时区和格式最容易错
ES 的 date_histogram 要求输入字段是 date 类型，且聚合结果的时间戳默认按 UTC 输出。你在 Go 里传 time.Now() 作为查询范围没问题，但若用 time.Local 构造 range 查询，又没在 ES 查询里显式指定 time_zone，结果就可能偏移 8 小时。更麻烦的是：Go 的 time.Format 和 ES 的 format 不兼容（比如 "2006-01-02" 在 ES 里得写成 "yyyy-MM-dd"）。
实操建议：
- 统一用 UTC 处理时间：Go 侧用
time.UTC，ES 查询里加"time_zone": "+00:00" -
date_histogram的interval写字符串，如"1d"、"1h"，别拼数字+单位变量（易错） - 格式化输出时间桶时，用 ES 返回的
KeyAsNumber（毫秒时间戳）转 Gotime.Time，别信Key字段的字符串值（它受 format 和 tz 影响） - 测试时故意改本地时区，看聚合边界是否滑动——这是最有效的验证方式
聚合不是查表，它是对倒排索引的一次重计算。每多一层嵌套、每多一个 size、每漏一个 .keyword，都可能让结果偏差或请求失败。调试时盯住三处：DSL 结构是否合法、响应体里 aggregations 字段是否存在、每个 bucket 的 DocCount 是否合理——别的都是浮云。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
