应将设备状态作为field而非tag写入，用stateduration()统计在线时长，并通过flux的queryapi.query解析table结构获取结果。
直接用 Flux 查询 + Go client 的 QueryAPI.Query 就能算，但必须确保设备状态打点带明确的 time 和 status 字段，且不能把 device_id 放 tag 里做高基数过滤。
设备状态必须用 field 记录，别塞进 tag
在线时长统计依赖连续的状态变化（如 status="online" → status="offline"），InfluxDB 的 elapsed()、difference() 等函数只对 field 值有效。如果把 status 当作 tag 写，它就变成 series 维度的一部分，无法参与时间差计算。
- ✅ 正确：用
AddField("status", "online")，status是 field，可被 Flux 按时间序列处理 - ❌ 错误：用
AddTag("status", "online")，这会让每个 status 变成独立 series，查不到跨状态的时间间隔 - ⚠️ 高危陷阱：若同时把
device_id放 tag，而设备数超 1 万，series 爆炸会导致查询超时或 OOM
Flux 查询语句要显式处理状态跳变
单纯 elapsed() 只算相邻两点时间差，不识别“上线→下线”逻辑。得用 stateChanges() 或窗口聚合来提取有效在线区间。
- 推荐写法（按设备分组，统计总在线毫秒）：
from(bucket: "metrics") |> range(start: -7d) |> filter(fn: (r) => r._measurement == "device_heartbeat" and r._field == "status") |> filter(fn: (r) => r.status == "online") |> elapsed(unit: 1ms) |> sum(column: "elapsed")
- 更严谨的做法是用
stateDuration()判断连续在线时长，再sum()：|> stateDuration(fn: (r) => r.status == "online", column: "duration", unit: 1s)
- 注意：
stateDuration要求数据严格按时间升序，Go 写入时务必调用SetTime(time.Now().UTC())，避免本地时区导致乱序
Go 中调用 QueryAPI.Query 要按列名取值，别信 CSV 解析
QueryAPI.QueryRaw 返回的是带 header 的 CSV，字段顺序不固定，null 值写作字符串 "NULL"，手动解析极易出错。必须用 QueryAPI.Query 走 flux.Table 结构。
- 关键步骤：遍历
Table的GroupKey()区分不同device_id（如果做了 group by），再逐行读Record.ValueByKey("duration")或"_value" - 错误示例：
record.Values()[2]—— 列序一变就崩，且没类型检查 - 时间精度陷阱：如果写入用的是毫秒时间戳，但没在
WriteOptions里设Precision: "ms"，Flux 查到的时间会偏移 10⁶ 倍，算出来的时长是错的
高频心跳场景下，别每秒都写 online 状态
设备每秒上报一次 status="online"，不是“更准”，而是制造海量冗余点，拖慢查询、撑爆 series 数。真实在线时长依赖的是“状态变更”，不是“状态快照”。
- ✅ 推荐策略：只在状态切换时打点（
online→offline或反向），配合客户端本地缓存上一次状态 - ✅ 折中方案：心跳保留，但用 Telegraf 的
distinct插件或 InfluxDB 的duplicate()函数去重，再喂给stateDuration - ❌ 硬扛：每秒写一条，7 天就是 604800 条/设备，1000 台设备 = 6 亿点，
range()扫描直接超时
最易被忽略的一点：InfluxDB v2.x 不支持 InfluxQL 的 GROUP BY time(1h) 直接套用在状态统计上——它只会把点按时间桶归并，但不会自动识别状态起止。必须用 Flux 的 stateDuration 或 aggregateWindow + 自定义函数，否则算出来的“在线时长”只是采样点数量乘以间隔，毫无业务意义。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
