InfluxDB 2.x 不支持 UPDATE 语句，所谓“更新”实为写入同 measurement、同 tags、同时间戳的新数据点以覆盖旧值；需严格保证时间戳（纳秒级精度）、tags（大小写及空格敏感）、measurement 和 field 名及类型一致，推荐用 PointV2 构造并避免先查后写。
更新InfluxDB数据在Go里没有“update”语句
InfluxDB 2.x（及云版）不支持 SQL 风格的 UPDATE 操作——它压根没有原地更新的概念。所谓“更新”，实际是写入一条**时间戳相同、tag 相同、field 值不同**的新数据点，覆盖旧值。InfluxDB 会自动用新点替代旧点（前提是 measurement + tag set + timestamp 完全一致）。如果你发现旧值没变，大概率是 timestamp 或 tag 对不上。
用 WriteAPI 写入同 key 新点实现逻辑更新
Go 官方 client（influxdb-client-go）只提供写入接口，你要自己确保写入点能覆盖旧点：
- 必须显式指定
time字段，且和原数据完全一致（纳秒级精度，别用time.Now()） - tag 键值对必须一字不差（包括空格、大小写），哪怕多一个空格也会写成新 series
- measurement 名和 field 名也要严格匹配；field 类型不能变（比如原先是
int，不能写float64） - 推荐用
PointV2构造，避免隐式类型转换导致写入失败
示例：
pt := influxdb2.NewPointV2("cpu",
map[string]interface{}{"usage": 85.2}, // field
map[string]string{"host": "server-01", "region": "us-west"}, // tags
)
pt.SetTime(time.Unix(1717023600, 0)) // 必须和原数据时间戳一致
writeAPI.WritePoint(ctx, pt)
先查后写？别这么做
InfluxDB 的查询（QueryAPI）返回的是只读结果流，无法直接定位到某条记录的物理位置。想“先查再更新”，你得自己解析 Flux 查询结果、提取 timestamp 和 tags，再拼回写入点——不仅慢，还可能因查询延迟或并发写入导致覆盖错乱。
立即学习“go语言免费学习笔记（深入）”；
- Flux 查询本身不保证强一致性，尤其在高写入场景下容易漏掉刚写入的点
- 两次 RPC（查 + 写）增大失败概率，中间若服务中断就只剩半截逻辑
- 真正需要“条件更新”的场景（如 usage > 90 才改 status），应该在应用层做判断，而不是依赖数据库原子性
注意 precision 和时区对时间戳的影响
写入时默认使用纳秒精度，但如果你从其他系统拿到的是秒级时间戳（比如 Unix 时间戳整数），直接传给 SetTime 会变成纳秒级大数，导致时间错位。
- 从 HTTP API 或日志解析拿到的
1717023600是秒，需转为time.Unix(1717023600, 0) - 如果原始数据带时区（如
"2024-05-30T12:00:00Z"），用time.Parse(time.RFC3339, s)解析，别手动拼时间 - client 默认按本地时区处理无时区时间字符串，容易出偏差；建议所有时间统一用 UTC 并显式标注
覆盖失效往往不是逻辑错，而是时间戳差了几个数量级或者时区悄悄变了。
