client.close() 是唯一安全关闭方式，必须在所有 writeapi.flush() 完成后调用，且长期服务中需通过信号监听触发而非 defer；queryapi 无需关闭但必须完整迭代结果。
client.Close() 是唯一安全关闭方式，不调就可能泄露连接
Go 客户端 influxdb2.Client 内部维护 HTTP 连接池、后台写入 goroutine 和定时 flush 任务。不显式调用 Close()，程序退出时这些资源不会自动释放——连接保持 ESTABLISHED 状态，后台 writer 可能仍在尝试重试失败点，甚至导致进程无法正常退出。
常见错误现象：
- 服务重启后出现
connection refused或too many open files—— 上次未 Close 的连接还在占着 fd - 日志里持续刷
write failed: context canceled—— writer goroutine 没被通知停止 - 测试用例跑完后 netstat 显示大量
TIME_WAIT连接
正确做法只有一条：所有通过 influxdb2.NewClient() 创建的 client 实例，必须在生命周期结束前调一次 client.Close()。
注意：Close() 是阻塞操作，会等正在 flush 的 batch 完成、所有后台 goroutine 退出才返回。生产环境建议配合 context 控制超时：
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()
err := client.Close(ctx)
if err != nil {
log.Printf("failed to close influxdb client: %v", err)
}
WriteAPI 不能单独 Close，它依赖 client.Close()
WriteAPI（包括 WriteAPIBlocking）是 client 的子对象，没有自己的 Close() 方法。它的生命周期完全绑定 client：client 关闭时，所有关联的 writeAPI 自动失效；若只丢弃 writeAPI 变量却不关 client，连接和 goroutine 依然活着。
容易踩的坑：
- 在函数里 new client → new writeAPI → return writeAPI，然后在别处调
writeAPI.Flush()—— 此时 client 可能已被 GC，但没 Close，后台任务卡住 - 把 writeAPI 当成可复用单例注入，却忘了 client 是顶层资源，必须统一管理
- 误以为
writeAPI.Flush()等价于关闭，其实它只提交缓冲区，不终止 writer goroutine
所以资源释放顺序固定为：writeAPI.Flush() → client.Close()。Flush 不是可选步骤，而是 Close 前的必要准备。
defer client.Close() 在 long-running service 里不适用
对常驻进程（如监控采集服务），defer client.Close() 会在函数返回时触发，但 main 函数一般不返回。这时候 defer 永远不会执行，等于没关。
真实场景要靠信号监听或 graceful shutdown 流程：
- 注册
os.Interrupt和syscall.SIGTERM信号处理器 - 收到信号后，先停止数据采集循环，再调
writeAPI.Flush()，最后client.Close() - 避免在 signal handler 里直接调
client.Close()（可能阻塞），应发 channel 触发 shutdown 协程
关键点：client.Close() 有实际 IO 和等待逻辑，不能在信号 handler 中同步执行。
QueryAPI 不需要额外关闭，但要注意 result 迭代完毕
QueryAPI.Query() 返回的是 influxdb2.QueryTableResult 迭代器，它本身不持有连接，底层复用 client 的 HTTP client。所以没有 QueryAPI.Close()，也不需要手动关。
但必须确保迭代完成：
- 漏掉
for table := range result.Tables()循环，或提前 break，会导致部分响应 body 未读完，HTTP 连接无法复用 - 不调
result.Err()检查迭代过程是否出错，可能掩盖网络中断问题 - record.ValueByKey() 返回 nil 时没判空，panic 后迭代中断，body 残留
这不是“关闭”问题，但效果类似：连接池逐渐耗尽，后续查询变慢或超时。本质是 Go http.Transport 对未读完 response body 的惩罚机制。
最易被忽略的点：client.Close() 必须在所有 WriteAPI.Flush() 完成之后调，且不能依赖 defer 在长期服务中生效；Query 结果不完整迭代，比不关 client 更隐蔽地拖垮连接池。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
