kafka-go.reader是go生产环境流式消费kafka的首选，因其原生支持context、offset提交与业务逻辑精确对齐、按partition自动分片、避免rebalance卡顿；sarama.consumergroup因setup/cleanup阻塞、errors通道需手动消费、offset易漏提交等问题不适配流式场景。
直接用 kafka-go，别碰 sarama 做流式消费——除非你已经在它上面踩过至少三次 goroutine 阻塞、rebalance 卡死、offset 漏提交的坑。
为什么 kafka-go Reader 是生产首选
不是因为它 API 简单，而是它把 Go 工程师最常掉进去的几个洞都提前封死了：context.Context 原生支持、位点提交逻辑收口在 CommitInterval 里、Reader 生命周期和 rebalance 解耦。而 sarama.ConsumerGroup 的 Setup() 和 Cleanup() 方法一旦含 DB 查询或 HTTP 调用，整个消费者组会卡住，rebalance 进程停摆，新 partition 分配不下去。
典型现象：describe groups 显示 CONSUMER-IDLE 或 UNKNOWN_MEMBER_ID，日志里却没报错；其实是 Setup() 被阻塞，心跳线程无法更新，broker 主动踢出成员。
-
kafka-goReader 按 partition 自动分片，天然适配 goroutine 并发处理，无需自己写 worker 调度 -
sarama的Errors()channel 必须持续消费，否则 AsyncProducer 内部 goroutine 永久泄漏 -
kafka-go的ReadMessage返回 error 后自动重试（可配MaxAttempts），sarama的错误要手动从Errors()通道取，漏读就静默失败
kafka-go Reader 必须调优的五项配置
默认配置只适合本地跑通 demo，一上生产就会积压、延迟高、位点丢失。关键不是“连得上”，是“不丢、不乱、不卡”。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
-
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，别信默认值（它可能是kafka.OffsetNewest，跳过历史消息）
sarama 同步 Producer 怎么才不丢消息
线上事故八成出在默认配置：它默认 RequiredAcks = sarama.NoResponse，Broker 挂了也返回成功。这不是 bug，是设计——它把可靠性决策权交给你。
- 必须设
config.Producer.RequiredAcks = sarama.WaitForAll，确保 ISR 全部写入才返回 - 必须开
config.Producer.Return.Successes = true，否则SendMessage不返回partition和offset，没法做幂等校验 - 必须配
config.Version，比如 Kafka 3.6+ 就得用sarama.V3_6_0，版本不匹配会静默失败或报UNKNOWN_TOPIC_OR_PARTITION - 别忽略
config.Producer.Timeout，建议设10 * time.Second，超时后主动返回 error，而不是无限 hang 住
Exactly-Once 在 Go 客户端里根本做不到
Kafka 的 Exactly-Once 语义依赖 broker 端事务协调器 + 幂等 producer + 事务型 consumer 三者协同，Go 客户端（包括 kafka-go 和 sarama）都不支持事务型 consumer。所谓“端到端精确一次”是伪命题。
能落地的只有 At-Least-Once + 幂等消费：
- 生产侧：启用
EnableIdempotence: true（sarama）或用kafka-go Writer的RequiredAcks: kafka.RequiredAcksAll - 消费侧：业务逻辑和 offset 提交必须包裹在同一数据库事务里（例如 pg 上写业务数据 + offset 表），不能依赖 Kafka 自动提交
- 禁用
AutoCommit: true，尤其在流式 pipeline 中——panic 或 crash 时，自动提交的 offset 和实际处理进度必然错位
真正难的不是连上 Kafka，是让 offset 提交和业务状态变更原子化。这点最容易被忽略，也最常在线上引发重复消费。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
