InfluxDB.Client.Write 卡主线程因同步阻塞 HTTP 请求；异步需“生产-消费”分离：带缓冲 channel + 单 writer goroutine，设合理 bufSize，安全关闭须清空 channel 后批量写入。
为什么直接用 InfluxDB.Client.Write 会卡住主线程
Go 官方客户端 influxdb1-client 的 Write 方法是同步阻塞的，底层走 HTTP 请求，网络延迟、服务端排队、序列化开销都会让调用方 goroutine 暂停。尤其在高并发打点场景下，大量 goroutine 堆积在 Write 调用上，CPU 没满但吞吐骤降，还可能触发超时或连接池耗尽。
异步写入不是加个 go client.Write(...) 就完事——那只是把阻塞转移到新 goroutine，没解决资源失控问题：没有限流、无错误反馈、无法重试、内存无限增长。
- 别裸写
go client.Write(...)：写入失败完全静默，数据丢了都不知道 - 避免无缓冲 channel 直接传点：生产者会卡在发送上，等消费者处理完才继续
- 注意
Point对象不能复用：它内部含 map 和 slice，多 goroutine 并发写会 panic
用带缓冲 channel + 单 writer goroutine 实现可控异步
最简可靠方案是“生产-消费”分离：业务代码往带缓冲 channel 发 Point，单独一个 goroutine 从 channel 拉取、批量组装、调用 client.Write。缓冲区大小决定最大积压点数，避免内存爆炸。
示例关键结构：
立即学习“go语言免费学习笔记（深入）”；
type AsyncWriter struct {
points chan *client.Point
client *client.Client
done chan struct{}
}
<p>func NewAsyncWriter(c <em>client.Client, bufSize int) </em>AsyncWriter {
return &AsyncWriter{
points: make(chan *client.Point, bufSize),
client: c,
done: make(chan struct{}),
}
}-
bufSize建议设为预期峰值 QPS × 2～5 秒（如 1000 点/秒 → 缓冲 3000～5000） - 启动 writer goroutine 后，必须显式调用
Close()关闭 channel，否则range永不退出 - 写入失败时不要 panic，应记录日志并丢弃该批点——InfluxDB 本身不保证 at-least-once，重试需幂等设计
批量写入时要注意 WriteOptions 的 timeout 和 consistency
单次 client.Write 支持传 client.BatchPoints，其内部已按 measurement 分组。但真正影响性能的是 client.WriteOptions 中的两个字段：
-
Timeout：默认 0（无限等待），建议设为5 * time.Second，避免单次请求拖垮整个 writer goroutine -
Consistency：生产环境慎用ALL或QUORUM，会显著增加写入延迟；ONE是默认且最常用选项
另外，BatchPoints 的 Database 和 RetentionPolicy 必须显式设置，空字符串会导致写入失败并返回 "database is required" 错误。
如何安全关闭异步 writer 并确保数据不丢失
服务退出时，不能直接关 channel 或杀 goroutine。要先停收新点，再清空 channel 剩余数据，最后调用 Write 发送最后一包。否则未消费的点就永远滞留在 channel 里了。
典型关闭流程：
func (w *AsyncWriter) Close() error {
close(w.points) // 停止接收
// 拉出剩余所有点，打包写入
var pts []*client.Point
for p := range w.points {
pts = append(pts, p)
}
if len(pts) > 0 {
bp, _ := client.NewBatchPoints(client.BatchPointsConfig{
Database: "mydb",
Precision: "ns",
})
for _, p := range pts {
bp.AddPoint(p)
}
return w.client.Write(bp)
}
return nil
}这个逻辑必须放在 writer goroutine 内部执行，不能由外部调用后立即返回——否则 range w.points 还在跑，close 会导致 panic。
真正的难点在于：channel 关闭时机、剩余点收集、最后一批写入的原子性，三者稍有错位就会丢数据或死锁。很多实现只 close channel 就结束，其实埋了静默丢点的坑。
