kafka-go.reader是go生产环境流式处理kafka的首选，因其无状态、按partition自动分片、context控制精准、offset提交与业务逻辑精确对齐，且避免rebalance卡顿和资源倾斜；sarama.consumergroup则因setup/cleanup阻塞、需手动partition调度、offset提交易中断等问题不适配流式场景。
kafka-go.Reader 是当前 Go 生产环境流式处理 Kafka 的首选，不是因为“更简单”，而是它在 context 控制、offset 提交粒度、内存行为上更贴近流式场景的真实需求。
为什么 kafka-go.Reader 比 sarama.ConsumerGroup 更适合流式消费
sarama.ConsumerGroup 要求你实现 Setup 和 Cleanup 方法，一旦里面含阻塞操作（比如数据库连接池初始化、HTTP client warmup），整个 rebalance 流程就会卡住——消费者组无法完成重分配，消息停止消费。而 kafka-go.Reader 是无状态、按 partition 自动分片的轻量级结构，不依赖 goroutine 生命周期协调，天然适配流式 pipeline 的横向扩缩容。
常见错误现象包括：消费突然停滞、CPU 使用率低但 lag 持续上涨、日志里反复出现 rebalancing group 却无新消息处理。
-
kafka-go.Reader默认每个实例只读一个 partition，配合PartitionWatchInterval可平滑响应 topic 分区变更 - sarama 需手动做 partition-aware worker 调度，否则容易出现单个 consumer 处理多个 partition 导致 CPU 或 I/O 倾斜
-
kafka-go.Reader的ReadMessage返回值直接带Offset和Partition，业务逻辑与位点提交可精确对齐；sarama的ConsumerGroupHandler.ConsumeClaim中 offset 提交需额外调用session.Commit，且易被 panic 中断
kafka-go.Reader 必须调整的 4 个关键配置项
默认配置只适用于本地调试：小流量下 MinBytes=10240 会导致消息积压几百毫秒才触发读取；不设 CommitInterval 则依赖 ReadMessage 成功后自动提交，一旦 handler panic 就丢 offset。
-
MinBytes: 1—— 强制最小读取字节数为 1，避免低频消息延迟升高 -
MaxWait: 100 * time.Millisecond—— 批处理等待上限，平衡吞吐与端到端延迟 -
CommitInterval: 1 * time.Second—— 显式控制提交频率，防止 panic 时 offset 丢失 -
PartitionWatchInterval: 30 * time.Second—— 动态扩容场景下降低 rebalance 频率，避免抖动
示例中常漏掉 MaxBytes（建议设为 1048576）和 StartOffset（流式处理通常从 kafka.FirstOffset 或 kafka.LastOffset 显式指定）。
如何在流处理中落地 At-Least-Once + 幂等消费
Kafka 本身不支持 Go 客户端实现端到端 Exactly-Once，所谓“事务型消费”本质是把业务处理与 offset 存储放在同一事务边界内。
- 不能依赖
AutoCommit: true，尤其在有外部依赖（DB、HTTP、缓存）的 pipeline 中 - 启用
EnableIdempotence: true（sarama）或使用kafka-go Writer的RequiredAcks: kafka.RequiredAcksAll - 消费侧必须将业务逻辑与 offset 提交放在同一事务边界内——例如用数据库事务包裹消息处理 + offset 写入 pg/kv 表
最容易被忽略的一点：offset 写入存储前，必须确保业务逻辑已成功执行且无 panic；否则哪怕用了数据库事务，也可能因提前 commit 导致重复处理。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
