必须显式处理时间精度、tag/field分离和错误捕获，否则数据查不到、series爆炸或静默丢点；go客户端默认按纳秒解析时间戳，毫秒级时间需转time.time并调用settime；高基数字段禁入tag以防series爆炸；writeapi需用blocking模式或手动flush并检查error。
直接用 influxdb-client-go/v2 写入即可，但必须显式处理时间精度、tag/field 分离和错误捕获——否则数据会查不到、series 爆炸、或静默丢点。
写入时 timestamp 总是错乱或被忽略？
根本原因是 Go 客户端默认按纳秒解析时间戳，而你传的 time.Now() 或 JSON 解析出的时间戳大概率是毫秒级。InfluxDB 不报错，但会把 1719804180000（毫秒）当成 1719804180000 纳秒（≈54年），导致数据“消失”在时间线之外。
- 构造
Point时必须调用.SetTime(t time.Time)，不能只靠字段拼接 - 若从字符串解析时间（如
"2026-07-06T11:23:00Z"），先用time.Parse(time.RFC3339, s)得到time.Time，再传给SetTime - 批量写入时，
WriteAPI不接受全局 precision 配置；得在每个Point上确保time.Time的精度一致（建议统一用.UTC()）
Tag 和 Field 混用导致查询变慢甚至 OOM？
InfluxDB 的索引只建在 tag 上，field 不索引也不参与分组。把高基数字段（如 request_id、user_agent、trace_id）塞进 tag，会触发 series 爆炸——每条唯一组合都生成一个新 series，内存和磁盘增长呈指数级。
- 只把低基数、高频过滤/分组字段放 tag：例如
host="web01"、region="us-east"、service="auth" - 所有原始值、指标值、日志内容一律进 field：
latency_ms=123.4、status_code=200、error_message="timeout" - Go 中构造
Point时，tags和fields是两个独立 map，别手滑把map[string]interface{}误传给 tag 参数
批量写入看似成功，实际部分点丢失？
WriteAPI.Write() 默认异步 + 缓冲队列，网络抖动、服务端限流（HTTP 429）、或单点校验失败时，错误常被吞掉，err == nil 但数据已丢。
- 禁用默认异步模式，改用
WriteAPIBlocking：它同步等待响应，错误不掩盖 - 或保留
WriteAPI，但必须手动调用w.Flush()并检查返回 error（Flush()才真正触发送出） - 更稳妥做法：用
client.WriteAPIBlocking(org, bucket)+ 显式WritePoint(ctx, p)，逐点控制并捕获 error - 别只看
len(points)，要检查err是否为nil；InfluxDB 对混合请求中部分失败点可能返回 warning 而非 error
最易被忽略的是 precision 和 tag 基数——它们不报错，但上线后查不到数据、Grafana 图表空、监控告警失灵，问题排查成本远高于初始化时多写两行代码。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
