使用 influxdb-client-go/v2 是唯一可靠选择，需正确配置 url（含协议端口）、token（带 bucket 写权限）和 org（大小写敏感的组织名），写入须设纳秒级 time.time，查询需迭代结果并加 yield()，批量写入后必须 flush() 并检查错误。
用 influxdb-client-go/v2 是唯一靠谱的选择，别碰 influxdb1-client 或手拼 HTTP 请求——连不上、写不进、查不到，八成是协议或权限错，不是代码逻辑问题。
初始化 client 时 URL、token、org 必须同时对
URL 必须带协议和端口（如 "http://localhost:8086"），漏掉 http:// 直接报 connection refused；token 不是 UI 里随便复制的 root 密码，得在 Load Data → Tokens 页面新建，且勾选对应 bucket 的 Write 权限；org 参数必须填组织 name（大小写敏感，空格也不行），不是 ID，也不是用户名，可在右上角头像 → Organizations 里确认。
常见错误现象：
-
401 Unauthorized：token 权限不足或 org 名不匹配 -
404 Not Found：URL 多写了/api/v2，或 bucket 名写错（比如my-bucket写成my_bucket） -
context deadline exceeded：URL 缺协议，或服务未启动
写入数据必须显式设 time.Time，不能靠默认
WriteAPI.WritePoint() 不报错 ≠ 数据已写入，更不等于时间戳有效。InfluxDB 2.x 要求每条数据带非零纳秒级时间戳，time.Time{} 或 0 时间会被静默丢弃。必须调用 point.SetTime() 传 time.Time 类型值，不能塞字符串或 Unix 秒数。
实操建议：
- 统一用
time.Now().UTC()，避免本地时区偏移 - 若从设备上报时间解析，务必用
time.Parse()得到time.Time再传给SetTime() - 高频打点时，用
time.Now().UTC().UnixNano()确保纳秒精度，否则同一秒内多条数据可能被覆盖 - 字段类型要对齐：
AddField("value", float64(95.2))，整数优先用int64，别传裸int
Query 返回空？不是没数据，是没迭代
queryAPI.Query() 返回的是 influxdb2.QueryTableResult 迭代器，不是数据切片。不手动调 result.Next()，就永远拿不到记录。Flux 查询还必须显式加 |> yield()，否则什么也不返回。
常见错误现象：
- 查询语句没错、bucket 有数据，但
result.Record()总是 nil —— 漏了for result.Next() { ... } - 查
range(start: -1h)没结果，实际数据在 2 小时前 —— 时间范围太窄 - 字段名含连字符（如
cpu-usage）却没用双引号，在 Flux 里写成r._field == "cpu-usage"
推荐写法用反引号包裹 Flux 字符串：`from(bucket:"my-bucket")|>range(start: -1h)|>yield()`，避免转义干扰。
批量写入不 flush 就等于没写
WriteAPI 默认异步缓冲，WritePoint() 成功只代表进缓冲区，不代表发出去了。错误藏在后台 goroutine 里，不主动 Flush() 并检查 Errors()，就会静默丢点。
实操建议：
- 程序退出前必须调
writeAPI.Flush()，然后立即读writeAPI.Errors()；别用defer，延迟执行可能来不及 - 高频场景下，用
WriteAPIWithOptions配BatchSize: 1000和FlushInterval: 1000，再配ErrorCallback捕获后台失败 - 遇到
429 Too Many Requests，不是代码问题，是 bucket 写入限频触发，得降频或升配 write limit
真正容易被忽略的，是 tag 基数控制——把 request_id 或 user_ip 塞进 tag，series 数暴涨，轻则写入卡顿，重则 OOM 崩溃。监控系统崩掉，往往不是并发高，而是 schema 设计错了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
