直接使用 kafka-go 而非自封装连接池，因其内部已实现带健康检查的 tcp 连接复用、自动重连、超时控制及 broker 发现机制；自行封装易引发 goroutine 泄漏、连接误判或 panic，且 v0.4+ 版本已支持 sasl/ssl、批量压缩与自动重试。
为什么直接用 github.com/segmentio/kafka-go 而不是自己封装连接池
Go 的 HTTP 客户端自带连接复用，但 Kafka/RabbitMQ/NSQ 等消息中间件客户端不是 HTTP 协议，底层 TCP 连接管理逻辑复杂。自己手写连接池容易在重连、超时、goroutine 泄漏上出问题。kafka-go 内部已实现带健康检查的连接池（Conn 复用 + Broker 自动发现），且默认启用 WriteTimeout 和 ReadTimeout。自行封装反而增加 net.Conn 生命周期误判风险，比如在 Close() 后继续调用 WriteMessages() 会 panic。
- 生产环境建议直接使用
kafka-gov0.4+，它支持 SASL/SSL、自动重试、批量压缩（CompressionCodec） - 避免用
gopkg.in/confluentinc/confluent-kafka-go.v1（Cgo 依赖，静态编译困难，内存占用高） - 若必须自研，至少把
net.Conn的SetDeadline和SetKeepAlive封装进连接工厂，否则长连接在 NAT 网关下易被静默断开
如何控制 WriteMessages 的吞吐与延迟平衡
WriteMessages 默认同步发送，每条消息都走一次 round-trip，吞吐低；全异步又难控背压。正确做法是组合使用 BatchSize、BatchBytes 和 BatchTimeout：
-
BatchSize: 100—— 每批最多 100 条，防单批过大 OOM -
BatchBytes: 1024 * 1024—— 单批上限 1MB，匹配 Kafka broker 的message.max.bytes -
BatchTimeout: 100 * time.Millisecond—— 防止小流量下消息积压过久
注意：这些参数必须在创建 kafka.Writer 时设置，运行时修改无效。如果业务对端到端延迟敏感（如实时风控），可设 BatchTimeout: 10 * time.Millisecond，但会略微降低吞吐；反之日志类场景可放宽到 500ms。
为什么 Reader 的 CommitMessages 必须显式调用且不能并发
Kafka 消费位点（offset）提交不是自动的。不调用 CommitMessages 会导致重复消费；并发调用则可能提交错 offset（例如 goroutine A 读到 offset=100，B 读到 105，但 B 先提交，A 后提交，最终位点回退到 100）。
- 务必在消息处理成功后立即调用
r.CommitMessages(ctx, msg)，不要 defer - 一个
Reader实例只能由单个 goroutine 调用FetchMessage和CommitMessages，这是kafka-go的设计约束，非 bug - 若需并行处理，应启动多个
Reader（每个绑定不同GroupID或不同Partition），而非让一个Reader被多 goroutine 共享
如何避免 context.DeadlineExceeded 导致消费者假死
常见错误是给 FetchMessage 传入短超时 context（如 context.WithTimeout(ctx, 5*time.Second)），一旦 broker 延迟抖动，FetchMessage 返回 context.DeadlineExceeded，但很多人忽略错误直接 continue，导致循环退出、goroutine 退出、消费者静默下线。
- 永远不要用短 timeout 包裹
FetchMessage，它本就是阻塞调用，应依赖Reader.Config.ReadTimeout控制单次网络等待 - 只对消息处理逻辑（如 DB 写入、HTTP 调用）设业务级 timeout，用独立 context 控制
- 捕获
context.DeadlineExceeded时，应记录 warn 日志并 continue，而不是 return 或 panic
真正影响可用性的不是单次超时，而是未区分网络错误和业务错误——把 broker 临时不可达当成逻辑失败，就容易误判服务状态。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
