fiber+clickhouse日志写入卡顿或oom主因是协议错配与批量控制不当：tcp端口误用http dsn导致静默超时；未复用连接池、单条insert触发频繁minor merge；须用preparebatch分批10000–50000行并调send，字段类型与时区严格对齐。
为什么 Fiber + ClickHouse 日志写入会卡住或 OOM
不是 Fiber 框架的问题，而是默认用 db.Exec() 或 stmt.Query() 写日志时，驱动走的是 TCP 协议块式传输，每条 INSERT 都触发一次小批量提交，MergeTree 持续 minor merge，CPU 和磁盘 IO 暴涨；更糟的是，若误用 HTTP DSN 连 TCP 端口（比如 http://localhost:9000），连接会静默超时，报 context deadline exceeded 却不提示协议错配。
- 确认 ClickHouse 实际监听端口：
telnet localhost 9000（TCP）或curl -v http://localhost:8123/（HTTP） - DSN 必须严格匹配：TCP 端口用
tcp://localhost:9000?secure=false&compress=false；HTTP 端口用http://localhost:8123?compress=true - Fiber 中不要在每个请求里新建
*clickhouse.Conn，复用全局连接池，否则连接数爆炸
如何用 Fiber 中间件安全写入百万级日志
别在 ctx.Next() 后直接 INSERT，要攒批、异步、防阻塞。Fiber 的并发模型依赖 goroutine，但 ClickHouse 写入必须控制节奏，否则压垮服务端或触发 max_insert_block_size 拒绝。
- 用
conn.PrepareBatch("INSERT INTO logs (...) VALUES (?, ?, ?)")，不是conn.Exec() - 每批控制在 10000–50000 行：太小（如 100）网络开销大；太大（如 200000）易被服务端拒绝或 GC 压力陡增
- batch.Append() 只是内存攒数据，漏掉
batch.Send()就等于没发；建议封装成带 channel 的 writer，由单独 goroutine 消费 - 日志字段含
Nullable(String)？Go 侧必须用*string接收，不能用string，否则扫描失败静默跳过
HTTP 流式查询日志时 JSONEachRow 解析失败
查历史日志时用 GET /?query=SELECT%20...&stream=1&format=JSONEachRow，响应体是每行一个 JSON 对象，但直接 json.Unmarshal([]byte) 全量读会 OOM；而 json.Decoder 逐行解码又常因时区或空值 panic。
- 务必设置
http.Client.Timeout = 300 * time.Second，ClickHouse stream 模式下连接可能长持 2 分钟以上 - 时间字段是
DateTime64(3, 'UTC')？Go 中构造条件必须显式用 UTC：t := time.Date(2024, 1, 1, 0, 0, 0, 0, time.UTC)，不能靠time.Now().UTC().Format(...)，后者可能丢毫秒精度 - 响应 Body 必须用
json.NewDecoder(resp.Body).Decode(&logRow)，且每次 Decode 前检查resp.Body是否已关闭（stream 模式下服务端可能提前断连） - 别调
rows.Columns()或rows.Err()在流式 HTTP 查询中——这些方法会触发完整结果拉取，绕过流式本意
日志表结构与 Fiber 日志字段映射常见错位
Fiber 默认日志是 plain text，直接写进 ClickHouse 会导致字段错乱或解析失败。必须在写入前做结构化转换，且字段名、类型、时区三者对齐。
- 埋点字段名全小写+下划线，如
user_id、status_code，和 ClickHouse 表字段严格一致 - 时间字段统一存为
DateTime64(3, 'UTC')，写入用toUnixTimestamp64Milli(now64())，查询用ts >= toDateTime64('2024-01-01 00:00:00', 3, 'UTC') - 避免
BETWEEN：ClickHouse 对 DateTime64 的边界处理有隐式截断，改用ts >= ? AND ts - 字符串字段推荐全用
String类型，不用FixedString或Enum，避免 Fiber 中动态日志内容长度溢出
关键点在于：Fiber 负责高并发接入和轻量日志采集，ClickHouse 负责存储与分析，中间那层「攒批 + 时区对齐 + 格式校验」不能省，也不能交给驱动自动猜。任何一步跳过，都会在百万级日志规模下暴露为静默失败或资源耗尽。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
