必须用 influxdb-client-go/v2，命令是 go get github.com/influxdata/influxdb-client-go/v2；老版无 token 认证、无重试、不支持缓冲，裸 http 易出错；初始化仅需 url 和 token，org/bucket 写入时指定。
用 influxdb-client-go/v2 初始化 client，别碰 v1 或裸 HTTP
直接上结论：必须用 influxdb-client-go/v2，命令是 go get github.com/influxdata/influxdb-client-go/v2。老版 influxdb1-client 没 Token 认证、无自动重试、不支持批量缓冲，写入丢点是常态；自己拼 HTTP 请求更危险——时间戳单位错、没连接池、错误难捕获。
初始化只传两个参数：influxdb2.NewClient("http://localhost:8086", "your_token")。org 和 bucket 是写入时才指定的，不是 client 构造参数。Token 必须提前在 InfluxDB UI 或 CLI 里配好 write 权限，且对应 org/bucket 已存在（SDK 不提供创建能力）。
如果是本地测试或自签名 HTTPS 环境，必须显式加配置：influxdb2.HTTPConfig{InsecureSkipVerify: true}，否则 TLS 握手失败静默卡住。
写入监控指标前，必须显式设 Precision 和 SetTime
最常踩的坑是时间戳单位错：InfluxDB 默认按纳秒解析，但 Go 的 time.Now() 在采集场景中通常是毫秒级（比如从 Prometheus Exporter 或 Telegraf 接收），不设精度会导致数据查不到、聚合结果错、甚至被静默截断。
务必在写入前指定 Precision，例如毫秒时间戳就得传 "ms"；SetTime() 必须调用，且推荐用 time.Now().UTC()，避免本地时区干扰。
字段类型也要对齐：AddField("cpu_usage", float64(95.2))，别传 int（32 位平台可能溢出），整数一律用 int64；字符串 tag 值不能含逗号、等号、空格，建议提前清洗：strings.ReplaceAll(v, " ", "_")。
别用 AddField 动态构造 Point，改用 NewPoint 批量初始化
实测发现，AddField 方法内部会对已有 field 循环遍历，field 越多 CPU 占用越高——这是 pprof 抓到的真实瓶颈。方式二（NewPointWithMeasurement().AddTag().AddField()）在高频率打点场景下会明显拖慢服务。
正确做法是方式一：influxdb2.NewPoint("cpu", map[string]string{"host": "web01", "env": "prod"}, map[string]interface{}{"usage_pct": 95.2, "load_avg": 1.2}, time.Now().UTC())。所有 tag 和 field 一次性传入，零额外循环开销。
如果 tag/field 字段名是动态生成的，也别在循环里反复调用 AddField，先组装好两个 map 再传给 NewPoint。
tag 和 field 分配必须严格遵循基数原则
把 request_id、user_ip、trace_id 这类高基数字段塞进 tag，会引发 series 爆炸——单个 measurement 的 tag 组合超过 10 万就该警觉，内存暴涨、写入卡顿、查询超时几乎是必然结果。
tag 只用于低基数、高频过滤字段：比如 host="web01"、service="auth"、env="prod"；判断标准就一条：这个字段是否常用于 WHERE 或 GROUP BY？取值是否少于几百个？满足才放 tag。
原始指标值（如 cpu_usage、memory_bytes、goroutines_count）一律进 field，InfluxDB 对 field 聚合极快，且不建索引也没关系。
真正容易被忽略的是：series cardinality 不是写完再看，而是要在埋点设计阶段就卡死。一旦上线后 tag 组合失控，删数据、重建 bucket 都救不回性能。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
