Go客户端查询返回QueryResult而非直接数据切片，需手动解析Results→Series→Values；新版QueryTableResult需循环Next()并校验Err，时间字段为time.Time，其他字段须类型断言；时间条件须客户端生成UTC绝对时间字符串，字段类型不一致时用type switch安全转换。
查询返回的是 QueryResult，不是直接的数据切片
Go 客户端（如 influxdb1-client 或官方推荐的 influxdb-client-go）执行查询后，不会直接返回 []map[string]interface{} 这类“开箱即用”的结构。你拿到的是一个封装了多组 Series 的 QueryResult 或 models.Response，必须手动遍历解析。
常见错误是试图对 result.Results 直接做 range 并取 .Values，却忽略 Err 字段或空 Series 情况——结果是 panic 或静默丢数据。
-
result.Results是[]*models.Result，每个Result对应一条 SQL 查询语句（支持多语句） - 每个
Result的Series是[]*models.Series，代表不同 measurement / tag 组合的结果集 - 真正的时间序列数据在
Series[0].Values，它是[][]interface{}：每行是[time, field1, field2, ...]
用 influxdb-client-go 解析 QueryTableResult 更直观
新版客户端（v2+）默认返回 QueryTableResult 流式结构，比老版 models.Response 更贴近“查完就用”的直觉，但需主动调用 .Next() 和 .Values()。
关键点在于：它不缓存全部结果，适合大数据量；但如果你习惯一次性读完，得自己收集到 slice。
立即学习“go语言免费学习笔记（深入）”；
- 检查
err := result.Err()必须在循环前或每次Next()后做，否则可能漏掉查询失败但无 panic 的情况 -
result.TableMetadata().ColumnNames()返回列名顺序，和result.Values()中[]interface{}的索引严格对应 - 时间字段类型是
time.Time，但其他字段可能是int64、float64、string或nil，类型断言前务必用_, ok := v.(float64)判断
for result.Next() {
values := result.Values()
timeVal := values[0].(time.Time)
cpuVal, ok := values[1].(float64)
if !ok { continue }
fmt.Printf("%v: %.2f\n", timeVal, cpuVal)
}
WHERE time >= now() - 1h 这类相对时间在 Go 里要提前算好
InfluxDB v2 的 Flux 查询不支持服务端解析 now() 后再传给 Go，所有时间条件必须由客户端生成绝对时间字符串（ISO8601 格式），否则会报错 invalid time value 或返回空结果。
尤其注意时区：InfluxDB 默认用 UTC 存储，但你的 time.Now() 是本地时区。不显式转 UTC，会导致查询窗口偏移。
- 正确写法：
time.Now().UTC().Add(-1 * time.Hour).Format(time.RFC3339) - 避免用
time.Now().Format("2006-01-02T15:04:05Z")—— 缺少毫秒位可能导致精度丢失（InfluxDB 默认存纳秒） - 如果查询涉及夏令时切换，用
time.Now().In(loc).UTC()显式指定所在时区再转，比直接UTC()更稳妥
字段类型不一致会导致 panic: interface conversion
同一个字段（如 value）在不同 batch 或不同 tag 组合下可能被 InfluxDB 推断为 float 或 integer，尤其当写入时混用了 123 和 123.0。Flux 查询返回的 Values() 就会交替出现 int64 和 float64，强制断言必崩。
最轻量的应对方式不是改写入逻辑，而是统一转成 float：
- 用
switch v := values[i].(type)分支处理int64、float64、nil - 对
int64做float64(v)，float64直接用，nil设默认值（如0.0） - 别依赖
reflect.TypeOf做运行时判断——性能差且掩盖了数据模型问题
实际解析逻辑往往卡在字段类型和时间处理这两处，而不是语法或连接配置。写完记得用真实乱序、含空值、跨天的数据跑一遍，比看文档更能暴露问题。
