生产环境应选 kafka-go 而非 sarama，因其 reader 无状态、自动分片、offset 提交与业务强对齐，规避 rebalance 卡死、errors 通道阻塞、手动提交漏失等风险；sarama 虽支持消费者组但需自行兜底三大问题。
为什么选 kafka-go 而不是 sarama
生产环境该用 kafka-go，不是因为它写起来短，而是它在流式消费场景下更少出错。sarama 的 ConsumerGroup 依赖 Setup() 和 Cleanup() 方法，一旦里面做了数据库连接、HTTP 初始化这类同步 I/O，整个 rebalance 就卡死，消费者组停摆；它的 Errors() 通道不持续读就会阻塞 goroutine，进程无法正常退出；offset 提交还得手动调 session.CommitOffsets()，panic 或提前 return 就漏提交，重复消费是常态。
kafka-go.Reader 是无状态的，按 partition 自动分片，不参与 group 协议，天然避开 rebalance 抖动。它把 offset 提交和业务逻辑对齐——ReadMessage 成功才提交，或用 FetchMessage + CommitMessages 手动控制，粒度更准。
- 别被 “sarama 功能全” 迷惑：它实现的是 Kafka 协议层，不是 Go 工程师要的流处理语义
- 如果你需要消费者组（多实例负载分摊），
sarama是唯一选择，但必须自己兜住 Setup/Cleanup 阻塞、Errors 通道消费、offset 漏提交这三座大山 -
kafka-go不支持原生消费者组，想横向扩缩容就得自己做 partition 分配和 offset 同步——多数业务其实不需要这么重的抽象
kafka-go.Reader 必须调优的四个配置项
默认配置只适合本地跑通，一上生产就延迟高、积压、位点丢失。这些值不是“建议”，是上线前必须显式覆盖的硬性要求：
-
MinBytes: 1：避免低频消息等满 10KB 才触发 fetch，否则端到端延迟飙升 -
MaxWait: 100 * time.Millisecond：太大会让实时性变差，太小则网络请求过于频繁 -
CommitInterval: 1 * time.Second：不设这个，就只能依赖ReadMessage自动提交，panic 时 offset 直接丢 -
PartitionWatchInterval: 30 * time.Second：topic 扩容或 broker 重启时，防止每秒都触发 rebalance 导致抖动
另外两个常被忽略：MaxBytes 建议设为 1048576（1MB），防止单次拉取过大卡住；StartOffset 必须明确设为 kafka.FirstOffset 或 kafka.LastOffset，别信“默认从 oldest 开始”的说法——实际行为取决于 broker 配置，不可控。
用 FetchMessage + CommitMessages 控制 exactly-once 语义边界
ReadMessage 是自动提交，适合监控类轻量任务；但只要业务逻辑涉及 DB 写入、HTTP 调用、文件落地，就必须用 FetchMessage。它只拉消息，不碰 offset，把提交时机完全交给业务代码判断。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
常见错误是：CommitMessages 被调在 goroutine 里，传入的 message 是值拷贝，内部无法关联原始 Reader 状态；或者没包 context.WithTimeout，网络抖动时卡死整个循环。
- 必须在同一个
kafka.Reader实例上调用CommitMessages，不能跨 Reader 提交其他 Reader 拉的消息 - 提交前检查业务是否成功，失败就跳过
CommitMessages，下次重试 - 用
context.WithTimeout(ctx, 5*time.Second)包一层再传给CommitMessages，避免 hang 住
Kafka 的 Exactly-Once 语义依赖 broker 端事务协调器 + 幂等 producer + consumer 事务读写组合，Go 客户端做不到。你能做的，只是把“处理成功 → 提交 offset”这段逻辑收得足够紧。
生产者别用 NewSyncProducer，除非你真懂 RequiredAcks
sarama.SyncProducer 看似可靠，但默认 RequiredAcks = sarama.WaitForLocal，只等 leader 写入就返回——leader 切换瞬间，未同步到 ISR 副本的消息就丢了。真正不丢的底线是：RequiredAcks = sarama.WaitForAll，且 Timeout ≥ 10s（Kafka broker 默认 request.timeout.ms=30000，客户端超时若更短，会提前报错中断，但 broker 可能还在重试）。
还有三个关键动作常被跳过：
- 不显式调
defer p.Close()：短生命周期服务容易触发too many open files - Topic 创建不用
ClusterAdmin：本地kafka-topics.sh创建的 topic 在集群中可能分区不均、副本未就绪 - 序列化用
sarama.ByteEncoder([]byte(""))，别用sarama.StringEncoder：后者对含\x00的二进制内容会截断
如果只是发日志或事件，kafka-go.Writer 更省心：它默认幂等、自动重试、支持 Balancer 策略，且没有 sarama 那套复杂的版本匹配和 replication.factor 校验陷阱。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
