WriteAPI.WritePoint()不报错≠数据已写入，因默认异步机制静默吞掉超时等错误；必须调writeAPI.Flush()并检查Errors()暴露真实错误，且需显式配置WriteOptions.Timeout防止goroutine阻塞。
WriteAPI.WritePoint() 不报错但数据没写进去，其实是超时被吞了
Go 客户端 influxdb-client-go/v2 的 WriteAPI.WritePoint() 默认是异步批量提交，调用成功只代表点进了缓冲队列，不保证发出去。网络超时、服务不可达、token 过期这些错误全被静默丢弃——你看到 err == nil，其实数据根本没离开本机。
真正暴露超时错误的唯一方式是主动触发 writeAPI.Flush()，然后立刻检查 writeAPI.Errors()。这个 error 会包含 context deadline exceeded、Post "http://...": dial tcp: i/o timeout 等真实底层错误。
- 别依赖
defer writeAPI.Flush()：程序退出前缓冲区可能已被清空，错误来不及捕获 - 调试阶段每次写完都加
writeAPI.Flush()+if err := writeAPI.Errors(); err != nil { ... } - 生产环境可改为定时 flush（如每 500ms），但必须确保 flush 后检查 Errors
初始化 client 和 writeAPI 时必须设超时，不能靠默认值
客户端本身不设超时，HTTP 底层就用 http.DefaultClient，而它的 Timeout 是 0（无限等待）。一旦 InfluxDB 响应慢或卡住，整个 goroutine 就挂死，Gin 请求链路直接阻塞。
正确做法是在创建 WriteAPI 时传入 influxdb2.WriteOptions，显式控制超时和重试：
立即学习“go语言免费学习笔记（深入）”；
-
Timeout: 5 * time.Second：单次写入操作上限，避免拖垮请求 -
RetryInterval: 1 * time.Second：网络失败后重试间隔（默认已启用重试） - 不要改
BatchSize或FlushInterval来“缓解”超时——那是吞吐问题，不是超时根源
示例：writeAPI := client.WriteAPIWithOptions("my-org", "my-bucket", influxdb2.WriteOptions{Timeout: 5 * time.Second})
网络超时发生时，别只打日志，得有 fallback
单纯记录 context deadline exceeded 没用。InfluxDB 写入失败意味着监控/采集数据丢失，必须补救。
- 高频写入场景（如传感器）：内存缓存最近 500 条失败点，用独立 goroutine 轮询重试，避免阻塞主流程
- 低频关键指标（如告警状态）：同步重试 2 次 + 指数退避，失败后落本地临时文件，后续人工导入
- 永远别在 Gin handler 里做重试循环——超时风险叠加，QPS 上去直接雪崩
注意：writeAPI.Errors() 返回的是最后一次 flush 的聚合错误，不是每条点的明细。若需粒度到点的失败原因，得用 WriteAPIBlocking（仅限低吞吐调试）
服务端配置也要匹配，否则客户端超时是假象
客户端设了 5 秒超时，但 InfluxDB 自身 write-timeout 是 10 秒，那实际卡住是服务端先断连接，客户端收到的是 connection reset by peer，不是超时 error。
- 查 InfluxDB 配置项：
[coordinator] write-timeout = "20s"（建议 ≥ 客户端 Timeout） - 如果启用了反向代理（如 Nginx），它也有自己的
proxy_read_timeout，必须比客户端超时更长 - 高并发写入时，
max-concurrent-queries设为 0（不限制）可减少排队，但得配合资源监控，防 OOM
最易忽略的一点：超时错误常和 DNS 解析卡顿混在一起。若用域名连 InfluxDB（如 http://influxdb.prod.svc），务必确认本地 DNS 缓存或 CoreDNS 响应及时，否则第一次解析就耗掉 4 秒，直接触发超时。
