influxdb-client-go/v2不暴露HTTP连接池配置，应聚焦WriteAPI的BatchSize和FlushInterval调优：设BatchSize为500、FlushInterval为1000毫秒，并配ErrorCallback捕获错误；全局复用client与writeAPI实例，程序退出前必须显式Flush()并检查Errors()。
influxdb-client-go/v2 不暴露连接池配置，但能间接控制
它内部用的是 http.Client，但没开放字段让你直接改 MaxIdleConns 之类。你真正能调的，是写入行为层面的“逻辑连接池”——也就是 WriteAPI 的缓冲与刷新策略。别在 HTTP 连接数上纠结，重点是批量攒点、错峰发包。
WriteOptions.BatchSize 和 FlushInterval 是关键参数
这两个值决定了实际发请求的频次和单次负载，直接影响底层 HTTP 连接复用率和吞吐稳定性：
-
BatchSize: 500—— 每攒够 500 条才触发一次 POST，太小（如 10）会高频建连；太大（如 5000）可能卡住或超时 -
FlushInterval: 1000（毫秒）—— 即使没攒够 BatchSize，1 秒也强制刷一次，防数据滞留 - 搭配
ErrorCallback捕获后台写失败，否则错误静默丢弃
示例初始化：
opts := influxdb2.WriteOptions{
BatchSize: 500,
FlushInterval: 1000,
ErrorCallback: func(err error) {
log.Printf("influx write error: %v", err)
},
}
writeAPI := client.WriteAPIWithOptions(org, bucket, opts)
Gin 或高并发服务里必须复用 client 和 writeAPI 实例
每次 HTTP 请求都 new 一个 client 或 writeAPI，等于每秒创建几十上百个独立连接器，连接池再大也扛不住：
- 全局只初始化一次
client := influxdb2.NewClient(...) - 全局只初始化一次
writeAPI := client.WriteAPIWithOptions(...) - handler 里直接用，别封装成闭包或局部变量
- 如果要用超时控制，通过
WriteOptions.Timeout设置（如5 * time.Second），不是改 HTTP client
程序退出前不调 Flush() 就等于没写
异步写入靠 buffer，writeAPI.WritePoint() 返回快不代表数据已发出。常见误操作：
- 用
defer writeAPI.Flush()—— main 函数 exit 前可能已被 GC 掉 buffer - 没检查
writeAPI.Errors()—— 错误藏在后台 goroutine，函数返回值永远 nil - 没等
writeAPI.Flush()完就os.Exit(0)—— buffer 里几百条全丢
正确收尾姿势：
if err := writeAPI.Flush(); err != nil {
log.Printf("flush failed: %v", err)
}
if err := writeAPI.Errors(); err != nil {
log.Printf("write errors: %v", err)
}
真正容易被忽略的是：InfluxDB 写入不是“发出去就完事”，而是“Flush() 成功 + Errors() 为空”才算落地。批量策略没调好，比连接池参数影响更大。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
