kafka-go.reader比sarama.consumergroup更适合流式消费，因其无状态、按partition自动分片、不依赖goroutine协调、offset提交与业务逻辑精确对齐，且避免rebalance卡顿和cpu/i/o倾斜。
为什么 kafka-go.Reader 比 sarama.ConsumerGroup 更适合流式消费
流式处理场景下，消费者卡顿、lag 持续上涨、rebalance 后无新消息，大概率不是 Kafka 集群问题，而是 sarama.ConsumerGroup 的生命周期模型和 Go 工程实践不匹配。
sarama 的 Setup() 和 Cleanup() 方法若含 DB 连接、HTTP 初始化等同步操作，会阻塞整个 rebalance 流程；而 kafka-go.Reader 是无状态的，每个实例只读一个 partition，天然规避了 goroutine 协调负担。
- 默认配置下，
sarama.ConsumerGroup的Offsets.Initial为 0，新 group 启动时查不到 offset 就报UnknownMemberId并退出 -
kafka-go.Reader不依赖 group.id，无需实现 rebalance 回调，partition 分配由客户端自动完成 -
sarama的 offset 提交需手动调用session.CommitOffsets()，panic 或提前 return 会导致漏提交；kafka-go.Reader.ReadMessage()返回值直接带Offset和Partition，业务逻辑与位点对齐更直观
kafka-go.Reader 必须调优的 4 个配置项
默认配置只适合本地调试：小流量下 MinBytes=10240 会让消息卡几百毫秒才触发读取；不设 CommitInterval 则依赖 ReadMessage 成功后自动提交，一旦 handler panic 就丢 offset。
-
MinBytes: 1：强制最小读取字节数为 1，避免低频消息延迟升高 -
MaxWait: 100 * time.Millisecond：批处理等待上限，设太大会拉高端到端延迟，设太小则网络请求频繁 -
CommitInterval: 1 * time.Second：显式控制提交频率，防止 panic 导致 offset 丢失；若业务要求强 at-least-once，建议配合CommitMessages手动批量提交 -
PartitionWatchInterval: 30 * time.Second：动态扩缩容或 broker 重启时，降低 rebalance 触发频率，避免抖动
如何安全地把消息消费与数据库事务对齐
“先写 DB 再 commit offset”是常见错误。如果 DB 写入成功但 offset 提交失败（如网络抖动），下次重启会重复消费；反过来，若先 commit offset 再写 DB，DB 失败就造成消息丢失——两者都破坏一致性。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
正确做法是将 offset 提交放在数据库事务 tx.Commit() 之后，并确保提交失败时能回滚整个流程。
- 不要用
consumer.CommitMessage(ctx, msg)自动提交——它不感知业务状态 - 改用
consumer.CommitOffsets(ctx, offsets)，其中offsets来自本次事务中成功写入的那批消息 - 若使用 PostgreSQL，可借助
pglogrepl或逻辑复制 + 本地 offset 表做最终一致性兜底；Kafka 事务在 Go 客户端里根本做不到端到端 Exactly-Once - 禁用
enable.auto.commit=true，这是最大陷阱：它按固定间隔（如auto.commit.interval.ms=5000）提交，不管业务是否执行完
sarama.AsyncProducer 在 HTTP handler 中怎么不阻塞
把 producer.Input() 放在 handler 主流程里，一旦 Kafka 集群短暂不可用，Input() channel 会阻塞（默认无缓冲），整个 HTTP 请求 hang 死。
必须解耦发送路径与请求生命周期，且不能靠无限重试掩盖设计缺陷。
- 用带缓冲的 channel 做异步中转，例如
ch := make(chan *sarama.ProducerMessage, 100)，handler 只负责塞消息，另起 goroutine 消费并发送 -
Config.Producer.Return.Successes = true必须开启，否则无法感知发送结果；同时监听Successes()和Errors()channel - 避免在 goroutine 里无超时地读
Successes()——日志峰值时 channel 可能堆积，改用select { case - 每次调用
producer.Close()，否则 goroutine 和 TCP 连接会泄露；broker 日志会出现Connection reset类错误
实际落地时最易被忽略的是：消费者 offset 提交时机必须严格绑定业务成功信号，而不是依赖任何“自动”机制；哪怕用了 kafka-go.Reader，没设 CommitInterval 或没做手动批量提交，照样丢消息。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
