kafka-go是go生产环境首选，因其流式消费更稳定、生命周期和位点提交更可控；sarama缺乏原生context支持、errors通道不消费会阻塞goroutine、setup/cleanup阻塞导致rebalance卡死、offset易漏提交。
kafka-go 是当前 Go 生产环境集成 Kafka 的首选，不是因为“更简单”，而是它在流式消费场景下更少出错、更容易控制生命周期和位点提交。
为什么默认不选 sarama
sarama 的设计偏向“协议层完整实现”，但对 Go 工程师日常要面对的流处理问题支持不足：
-
sarama.AsyncProducer的Errors()通道必须持续消费，否则内部 goroutine 会永久阻塞，进程无法退出 -
sarama.ConsumerGroup的Setup()和Cleanup()若含同步 I/O（如 DB 连接、HTTP 调用），会卡住整个 rebalance 流程，导致消费者组长时间不可用 - offset 提交需手动调用
session.CommitOffsets()，panic 或提前 return 时极易漏提交，引发重复消费 - 没有原生
context.Context支持，超时、取消、链路追踪都得自己包一层
kafka-go Reader 必须显式调优的配置项
默认配置只适合本地调试，一上生产就会出现消息延迟高、积压、位点丢失等问题：
-
MinBytes: 1：避免小流量下因等待凑够 10KB 而卡住，尤其在事件驱动型服务中 -
MaxWait: 100 * time.Millisecond：平衡单次拉取延迟与吞吐，设太大会让实时性变差，设太小则频繁网络请求 -
CommitInterval: 1 * time.Second：必须设置！否则依赖ReadMessage自动提交，一旦 handler panic 就丢 offset -
PartitionWatchInterval: 30 * time.Second：动态扩缩容或 broker 重启时，防止每秒都触发 rebalance -
StartOffset建议明确设为kafka.FirstOffset或kafka.LastOffset，别依赖默认值
Exactly-Once 在 Go 客户端里根本做不到
Kafka 的 Exactly-Once 语义依赖 broker 端事务协调器 + 幂等 producer + consumer 事务读写组合，Go 客户端无法绕过这些限制：
-
kafka-go和sarama都不支持事务型 consumer（即read_committed+isolation.level=transactional的完整链路） - 所谓“端到端精确一次”在 Go 应用层是幻觉；能落地的只有
At-Least-Once + 幂等消费 - 幂等关键在业务层：用
msg.Key或headers["idempotency-id"]做去重，而不是指望客户端自动处理
真正难的从来不是连上 Kafka，而是当流量突增、broker 暂时不可用、consumer panic 后恢复时，你的 offset 是否还准、消息是否还在预期顺序里、下游系统会不会被同一条消息打穿。这些细节藏在 CommitInterval、MaxWait、错误重试策略和 handler 的 recover 逻辑里，而不是在“怎么创建 Reader”这一步。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
