WriteAPIBlocking 是唯一真正的同步写入方式，它阻塞 goroutine 直至 HTTP 响应返回，不缓存、不批处理、不重试，100 条数据即 100 次独立请求，超时默认 10 秒且不可关闭。
WriteAPIBlocking 是唯一真正的同步写入方式
Go 官方 influxdb-client-go v2+ 中，没有“设置成同步”的开关，只有两个独立的 API 接口：WriteAPIBlocking（同步）和 WriteAPI（异步）。想强制每条数据都等服务端确认再返回，就必须用 WriteAPIBlocking，而不是在 WriteAPI 上调各种参数“模拟”同步。
-
WriteAPIBlocking.WritePoint()会阻塞当前 goroutine，直到 HTTP 响应返回（成功或明确错误），适合调试、单点上报、低频校验 - 它不缓存、不批处理、不重试——每次调用都是独立 HTTP 请求，100 条数据 = 100 次 round-trip
- 默认超时是 10 秒，可通过
client.Options().SetTimeout()调整，但无法关闭超时（必须设值） - 别把它和
WriteAPI混用：同一个 client 实例下，WriteAPIBlocking和WriteAPI共享底层连接池，但行为完全隔离
WriteAPI 不能靠参数变成“同步”，但可退化为强一致性
有人试图用 WriteAPI + 极小 batch 和 flush 设置来“假装同步”，比如 SetBatchSize(1).SetFlushInterval(0)。这确实会让写入延迟接近同步，但本质仍是异步队列驱动，存在风险：
- 即使 batch=1，数据仍先进入内存 buffer，再由后台 goroutine 提交；若程序 crash 或未调
Flush()/Close()，最后那条就丢了 -
SetFlushInterval(0)不代表立即 flush，而是禁用定时器，只靠数量触发；若没凑够 batch，它就一直卡着 - 网络超时或 429 错误时，
WriteAPI会自动重试（默认 5 次），而WriteAPIBlocking直接返回错误，行为更可预测 - 真正需要强一致语义（如关键告警事件），应优先选
WriteAPIBlocking，而非在WriteAPI上做高危 hack
时间戳必须显式传入，否则不是“同步”问题而是数据错乱
无论用哪种 API，如果没给 NewPoint() 传时间戳，InfluxDB 会用服务端接收时刻打时间戳——这跟“同步/异步”无关，但会导致数据时间线漂移，尤其跨时区或高延迟链路下。
- 前端传 ISO8601 字符串？先
time.Parse(time.RFC3339, s)，再.UnixNano() - 用
time.Now().UTC().UnixNano()，别用.Local()，InfluxDB 内部全按 UTC 存储和查询 - Line Protocol 对时间精度敏感：
WriteAPI默认按毫秒对齐，若你传纳秒但没配precision，可能被截断 - 构造
Point时漏掉时间戳参数，等于把时间控制权交给网络延迟和服务器负载
别忽略 WriteAPIBlocking 的隐式依赖
用 WriteAPIBlocking 并不意味着可以省掉所有工程细节。它只是简化了并发模型，但以下三点仍必须手动处理：
立即学习“go语言免费学习笔记（深入）”；
- Token、bucket、org ID 错误时，它返回的是
404 Not Found或401 Unauthorized，不会告诉你具体哪项错了，需提前验证 - Tag 和 Field 名含空格、逗号、等号？Line Protocol 解析失败，HTTP 却返回 204（成功），数据静默丢弃——
WriteAPIBlocking同样中招 - 高频调用时（如每毫秒一条），HTTP 连接复用不足会导致
dial tcp: lookup ...: no such host或connection refused，得确保 client 初始化时用了合理http.Client配置（如MaxIdleConnsPerHost）
同步写入的代价是确定性换吞吐，真要每条都等确认，就老实用 WriteAPIBlocking；但凡有一点并发或频率需求，就得切回 WriteAPI 并认真管好 Flush() 和生命周期——这两条路没有中间态。
