核心是固化token/org/bucket初始化、时间精度控制、tag/field分离、错误捕获和flush时机五件事；否则必现查不到数据、series爆炸、静默丢点。
直接用 influxdb-client-go/v2 封装通用数据访问层，核心不是“写个 wrapper”，而是把 token/org/bucket 初始化、时间精度控制、tag/field 分离、错误捕获和 flush 时机这五件事固化下来——否则每次调用都得重复处理，上线后查不到数据、series 爆炸、静默丢点全是必然。
为什么不能只 new Client + WriteAPI 就完事？
因为 WriteAPI.WritePoint() 返回无 error 不代表数据已落库；time.Now() 默认精度不等于 InfluxDB 要的纳秒；tag 里混进 request_id 这种高基数字段，10 分钟就能让内存翻倍；org 填错大小写或用了 ID 而非 name，连 401 都不报，直接 404。
-
client.WriteAPI(org, bucket)必须在每次写入前确认org和bucket存在且权限匹配，SDK 不校验 - 所有
Point必须显式调用.SetTime(t time.Time)，不能依赖构造函数自动填时间 -
tagsmap 的 key/value 都要提前过滤：去掉空格、逗号、等号；fields的 int 类型统一用int64，避免 32 位平台溢出 - 别在循环里反复
newPoint()，改用influxdb2.NewPointWithMeasurement()链式构建，减少 GC 压力
怎么封装 WriteAPI 才真正可靠？
关键不是隐藏接口，而是把异步缓冲的风险收口：强制 flush + 检查 errors + 设置重试退避。默认的 WriteAPI() 是“发出去就不管”，而生产环境必须知道“这批点到底有没有发成功”。
- 初始化时用
client.WriteAPIWithOptions(org, bucket, influxdb2.WriteOptions{BatchSize: 1000, FlushInterval: 1000, RetryInterval: 1000}) - 写入后必须立刻调
w.Flush()，再立即读w.Errors()——defer w.Flush()在 panic 或 os.Exit 时根本不会执行 - 为
ErrorCallback注册日志钩子，捕获后台 goroutine 中的WriteError（比如 429 Too Many Requests 或网络超时） - 若采集程序是短生命周期（如 CLI 工具），
Flush()后还要time.Sleep(50 * time.Millisecond)，确保 buffer 真的清空
Query 怎么封装才不会返回空 slice？
Go SDK 的 QueryAPI.Query() 返回的是迭代器，不是数据。封装时如果漏掉 result.Next() 循环或 Flux 脚本没写 |> yield()，结果永远是空——而且不报错。
立即学习“go语言免费学习笔记（深入）”；
- Query 方法必须接收完整 Flux 字符串（建议用反引号包裹），不要拼接：
`from(bucket:"${bucket}")|> range(start: -1h)|> filter(fn: (r) => r._measurement == "${m}")|> yield()` - 必须手动遍历：
for result.Next() { record := result.Record(); ... }，result.Err()要在循环结束后检查 - 时间范围参数不要硬编码，封装成
start time.Time和stop time.Time，内部转成 RFC3339 字符串传入 Flux - 字段名含连字符（如
cpu-usage）必须双引号包裹：r._field == "cpu-usage"，否则解析失败且静默跳过
最易被忽略的是 precision 和 tag cardinality 控制——它们从不报错，但一旦出问题，Grafana 图表就是空的，告警规则全失效，排查时却找不到 error 日志。
