应使用 influxdb-client-go/v2 初始化客户端，它支持 Token 认证、批量缓冲、自动重试和纳秒级时间控制；务必显式设置时间戳精度与 tag 基数，避免数据丢失或系统崩溃。
用 influxdb-client-go/v2 初始化 client 就对了
别碰 influxdb1-client，也别自己拼 http.Client 发 POST /api/v2/write——丢点、没重试、时间戳错乱是常态。当前唯一靠谱的选择是 influxdb-client-go/v2，它原生支持 Token 认证、批量缓冲、自动重试和纳秒级时间控制。
安装命令必须带 /v2：go get github.com/influxdata/influxdb-client-go/v2；初始化时只传 URL 和 Token：influxdb2.NewClient("http://localhost:8086", "your_token")。org 和 bucket 是写入时才指定的参数，不是 client 构造参数。
务必提前在 InfluxDB UI 或 CLI 创建好 org 和 bucket，SDK 不提供创建接口；Token 需有对应 bucket 的 write 权限。如果连接的是自签名 HTTPS 或本地测试环境，需显式配置：influxdb2.HTTPConfig{InsecureSkipVerify: true}。
写入监控指标前必须显式控制时间戳精度
监控打点时间戳单位错，会导致数据查不到、聚合结果错、甚至被静默截断。InfluxDB 默认按纳秒解析，但 Go 的 time.Now() 在多数采集场景中（比如从 Prometheus Exporter 或 Telegraf 接收）实际是毫秒级。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 不要依赖默认精度：写入前必须显式指定
Precision，例如毫秒时间戳就得设"ms" - 构造
Point时，SetTime()必须调用，且推荐用time.Now().UTC()，避免本地时区干扰 - 字段类型要对齐：
AddField("cpu_usage", float64(95.2))，别传int（32 位平台可能溢出），整数用int64或加后缀如8i - 字符串 tag 值不能含逗号、等号、空格，否则 Line Protocol 解析失败；建议提前清洗：
strings.ReplaceAll(v, " ", "_")
批量写入时 series cardinality 控制比吞吐量更重要
把高基数字段（如 request_id、user_ip、trace_id）塞进 tag，会引发 series 爆炸，内存暴涨、写入卡顿、查询超时——这是监控系统崩掉最常见的原因。
- tag 只用于低基数、高频过滤字段：比如
host="web01"、service="auth"、env="prod" - 原始指标值（
latency_ms、http_status、error_count）一律进field，不建索引也没关系，InfluxDB 对field聚合极快 - 判断标准就一条：这个字段是否常用于
WHERE或GROUP BY？取值是否少于几百个？满足才放tag - 单个
measurement的 tag 组合总数（series 数）超过 10 万就该警觉；InfluxDB 官方建议控制在 10 万以下
WriteAPI 调优和退出前 flush 是硬性操作
WriteAPI 默认异步缓冲，但不调优就容易吞吐低、报错漏检、内存堆积。程序退出前若不 Flush()，buffer 里未发的数据直接丢失。
- 推荐配置：
BatchSize: 1000（攒够千条再发）、FlushInterval: 1000（毫秒级强制刷）、ErrorCallback捕获后台错误 - 别每条都调
WritePoint()：单次写入几百上千点才调一次Flush()，否则 HTTP 开销压垮服务端 - 程序退出前务必调
writeAPI.Flush()并检查返回error - 遇到
429 Too Many Requests不是代码问题，是 bucket 写入限频触发了，得降频或升配 write limit
最易被忽略的是时间戳精度和 tag 基数控制——前者导致数据“存在却查不到”，后者让系统在流量高峰时无声崩溃。这两处不提前设防，后面排查成本远高于初始化时多写两行配置。
