应直接调用WritePoint写单条数据，避免用WriteBatchPoints封装单点；需显式指定database、retentionPolicy和precision（推荐Ms），严格区分field类型（int64加i、float64无后缀、string加引号），传入有效时间戳，错误直接检查返回err。
用 WritePoint 写单条数据，别用 WriteBatchPoints 硬塞一个点
Go 客户端写 InfluxDB 单条数据，最直接的方式是调用 client.WritePoint，不是把一个 Point 塞进 BatchPoints 再写——后者多一层封装、多一次切片分配，还容易因 batchSize 或超时设置导致延迟或丢点。
关键点：
-
WritePoint底层仍走 HTTP POST /write，只是帮你封装了序列化和请求构造，语义清晰、无额外开销 - 必须指定
database和retentionPolicy（哪怕用默认的autogen），否则返回 400 错误：{"error":"database is required"} - 时间戳建议显式传入
time.Now()或更精确的time.Unix(…)；不传会由 InfluxDB 服务端打时间戳，可能造成时序错乱
构造 client.Point 时字段类型要对得上，别混用 string 和 int64
InfluxDB 的 line protocol 对字段类型敏感：同个 field key 后续写入类型不一致（比如先写 value=123i，再写 value="abc"），会直接拒收并报错：{"error":"field type conflict"}。Go 客户端不会自动转换，全靠你传进去的值类型决定最终写入类型。
正确做法：
立即学习“go语言免费学习笔记（深入）”；
- 整数用
int64（加i后缀），例如map[string]interface{}{"count": int64(42)} - 浮点数用
float64（无后缀），例如{"temp": 23.5} - 字符串用
string（自动加双引号），例如{"status": "ok"} - 布尔值用
bool，例如{"active": true}
常见坑：从 JSON 解出来的数字默认是 float64，即使它看起来是整数；如果业务逻辑要求整型 field，得手动转成 int64 再塞进去。
写失败时检查 err 而不是只看 HTTP 状态码
client.WritePoint 返回的 error 已经包含了底层 HTTP 错误、JSON 解析失败、连接超时等全部情况。不要自己去抓 response.Body 再解析 —— 客户端已帮你做了。
典型错误场景与应对：
-
Post "http://localhost:8086/write?db=mydb&rp=autogen": context deadline exceeded：网络不通或 InfluxDB 挂了，需重试 + 超时控制 -
unable to parse '...': bad timestamp：传入的时间戳格式非法，检查是否用了time.Time零值或纳秒级时间戳未对齐 -
field type conflict：如上所述，同一 field key 类型不一致，需统一数据源类型或改用不同 field 名 - 静默失败（无 error 但数据没出现）：大概率是 database 或 retention policy 名写错，或 InfluxDB 启用了认证但 client 未配
user/password
别忽略 precision 参数，默认是纳秒，但多数场景用 ms 更稳
WritePoint 第四个参数是 precision，控制时间戳单位。默认是 ""（即纳秒），但实际中纳秒级时间戳容易溢出、调试困难，且多数传感器/业务数据到毫秒级已足够。
推荐显式指定：
- 用
influxdb.Ms（对应"ms"）—— 时间戳传time.Now().UnixMilli()，最常用也最不易出错 - 避免用
influxdb.S（秒）—— 若时间戳精度不足，多个点可能被压缩成一条（InfluxDB 对相同时间戳+相同 series 的点会合并） - 若真要用纳秒，确保传的是
time.Now().UnixNano()，而不是.Nanosecond()（后者只返回纳秒部分，不是自 epoch 起的纳秒数）
这个参数一旦写错，时间戳会偏移几个数量级，查数据时完全对不上，而且没有明显报错，特别难排查。
