influxdb-client-go/v2 默认开启重试，但仅3次固定间隔（1秒），无指数退避或抖动；生产建议设maxretries为5～8，配合retryinterval调优，并务必通过errorcallback或errors()通道捕获重试失败。
influxdb-client-go/v2 的重试机制默认开不开？
默认是开的，但只做 3 次固定间隔重试（每次等 1 秒），不带指数退避或抖动。这个策略对瞬时网络抖动够用，但面对 InfluxDB 服务端限流（429 Too Many Requests）、长时断连或高负载场景，容易失败漏点。
WriteOptions.RetryInterval 和 MaxRetries 怎么配？
这两个参数必须一起调，单独改没用。重试逻辑由 influxdb2.WriteOptions 控制，不是 HTTP client 层面的通用重试。
-
RetryInterval是每次重试前等待的毫秒数，不是总超时；设太小（如100）可能触发服务端限流，设太大（如5000）会拖慢恢复速度 -
MaxRetries默认为 3，建议生产环境设为5～8，再高意义不大——buffer 可能先满，错误已进Errors()通道 - 注意：它不会自动降频写入节奏，重试失败后仍按原 BatchSize 继续攒点，得靠
FlushInterval和监控Errors()主动干预
怎么捕获并响应重试失败？
重试失败不抛给 WritePoint() 调用方，而是异步发到 WriteAPI.Errors() 通道或触发 ErrorCallback。只检查函数返回值会漏掉全部真实错误。
- 必须传
ErrorCallback：比如func(err error) { log.Printf("influx write failed after retries: %v", err) } - 定期从
writeAPI.Errors()读取，尤其在程序退出前writeAPI.Flush()后要检查返回 error - 遇到
429错误，不能只重试，得降频：减小BatchSize、拉长FlushInterval，或加个全局写入速率限流器
要不要自己封装一层重试？
没必要。influxdb-client-go/v2 的重试已覆盖连接失败、5xx、429 等典型错误，且和批量缓冲、flush 时机深度耦合。自己在外层套 retry 函数反而会干扰 buffer 管理，导致重复写入或 panic。
真正要动手的是错误分类响应：比如 401 Unauthorized 就该 reload token，404 检查 bucket 名，context.DeadlineExceeded 调大 timeout——这些都在 ErrorCallback 里做，别塞进通用重试逻辑。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
