压测脚本必须复用单个influxdb2.Client实例，使用WriteAPIBlocking批量写入（每批2000–5000点），避免新建Client和逐点写入；构造Point须用influxdb2.NewPoint防转义错误；并发需限速，从10 goroutine起逐步加压并监控服务端指标。
用 influxdb2.Client 写压测脚本前先确认连接模式
InfluxDB 2.x 官方 Go SDK 默认走 HTTP API（非 InfluxQL，而是 Flux 或写入 Line Protocol 的 /api/v2/write），不支持直接复用 TCP 连接池或长连接“管道”。压测时如果每条数据都新建 influxdb2.NewClient，会迅速耗尽本地端口并触发 dial tcp: lookup failed 或 too many open files。必须复用单个 client 实例，并通过 client.WriteAPIBlocking 或 client.WriteAPI 控制并发写入。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 初始化一次
client := influxdb2.NewClient("http://localhost:8086", "my-token")，全局复用 - 避免在 goroutine 内反复调用
influxdb2.NewClient - 若压测目标是集群，确保 URL 指向负载均衡入口，而非单节点 IP（否则压测流量打偏）
批量写入必须用 WriteAPIBlocking 而非逐点 WritePoint
常见错误是循环里对每个 Point 调用 writeAPI.WritePoint，这会导致每条数据发一次 HTTP POST，QPS 上不去还容易被服务端限流。InfluxDB 压测吞吐量的关键在于「攒批 + 并发」：一批 1000–5000 行 Line Protocol 数据打包发送，配合多 goroutine 并行提交。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
writeAPI := client.WriteAPIBlocking("my-org", "my-bucket")获取阻塞式写入器（更易控制节奏） - 每次构造
influxdb2.NewPoint后，统一 append 到 slice，满 2000 条就writeAPI.WritePoint(ctx, point)批量提交 - 不要用
WriteAPI（非阻塞版）+ 自己做 channel 缓冲——容易丢数据且难以对齐成功率统计 - 注意
ctx设定超时，例如ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)，防止某批卡死拖垮整体
Line Protocol 构造不当会触发 400 Bad Request 或写入静默失败
InfluxDB 对 tag key、field value 类型、timestamp 格式非常敏感。压测脚本里硬编码字符串拼接 Line Protocol 是高危操作，比如 "cpu,host=server01 usage=23.4 1712345678900000000" 中的空格、逗号、等号未转义，或 timestamp 用了秒级而非纳秒级，都会导致整批被拒绝，但 SDK 默认不报具体错误（只返回 nil error 且无日志）。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 永远用
influxdb2.NewPoint构造，别手拼字符串——它自动处理 tag key/value 转义、field 类型推断、timestamp 归一化 - tag value 若含空格、逗号、等号、换行符，
NewPoint会自动加双引号；手动拼接时漏掉就 400 - timestamp 必须传
time.Time，不要传 int64 纳秒值——SDK 内部会转换，传错类型可能被忽略 - 压测前先用
curl -i -XPOST 'http://localhost:8086/api/v2/write?org=my-org&bucket=my-bucket' --data-binary 'm,tag=a field=123'验证基础写入通路
并发控制不设限会导致 InfluxDB OOM 或写入延迟飙升
Go 脚本起 1000 个 goroutine 往 InfluxDB 发数据，看起来 QPS 高，实际可能让服务端 WAL 积压、内存暴涨甚至 crash。InfluxDB 的写入吞吐瓶颈常在磁盘 I/O 和 TSM 文件压缩，不是网络。压测不是比谁发得快，而是测出服务端稳定承载的上限。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
semaphore或带缓冲 channel 控制并发写入 goroutine 数量，从 10 开始逐步加压（如 10 → 50 → 100） - 每轮压测固定时长（如 30 秒），记录
writeAPI.WritePoint的平均耗时、失败率、服务端httpd_request_duration_seconds指标 - 观察 InfluxDB 自身指标：
runtime_mem_stats_alloc_bytes是否持续上涨、tsm1_wal_writes_total是否远高于tsm1_cache_bytes—— 这说明 WAL 写不过来 - 避免用
time.Sleep做节奏控制，改用rate.Limiter（golang.org/x/time/rate）实现平滑限速
真正难调的是服务端参数和硬件匹配度，比如 cache-max-memory-size 设太小，批量写入反而触发频繁 flush，压测结果失真。脚本只是探针，别让它成为瓶颈本身。
