选 kafka-go 更适合新手：api 直白，dialleader 和 newreader 两步即可跑通；sarama 功能全但配置复杂，易因超时/重试未设导致静默失败。
用 sarama 还是 kafka-go？选错客户端会卡在第一步
刚上手时最容易卡在「连不上」或「发不出」——往往不是 Kafka 没启，而是客户端选错了。sarama 功能全但配置重、goroutine 多，新手容易因超时/重试没设好直接静默失败；kafka-go（segmentio/kafka-go）API 更直白，dialLeader 和 NewReader 两步就能跑通，适合验证逻辑或中小流量场景。
关键区别：
-
sarama：必须显式设置config.Net.DialTimeout、config.Producer.Retry.Max，否则网络抖动就断连不重试 -
kafka-go：默认带重试，ReadTimeout和WriteTimeout需手动设，否则消费者可能 hang 在ReadMessage - 若要用事务或精确一次语义，sarama 支持更完整；仅需异步通知或日志采集，kafka-go 足够且更轻
生产者发不出消息？90% 是 RequiredAcks 和错误通道没管
同步生产者看似简单，但 SendMessage 返回成功 ≠ 消息已落盘。Kafka 默认 RequiredAcks = NoResponse，Broker 接收即返，网络丢包或副本未同步都会导致静默丢失。
必须做的三件事：
立即学习“go语言免费学习笔记（深入）”；
- 设
config.Producer.RequiredAcks = sarama.WaitForAll（或kafka-go中RequiredAcks: kafka.RequireAll） - 启动 goroutine 监听
producer.Errors()（sarama）或检查err返回值（kafka-go），不能只看SendMessage是否 panic - 消息体加
trace_id字段，否则线上出问题根本没法对齐日志
示例（sarama）：go func() { for err := range producer.Errors() { log.Printf("kafka send error: %v", err) } }()
消费者堆积、反复 rebalance？先查 session.timeout.ms 和处理耗时
多个实例一启动就疯狂触发 rebalance，消费延迟飙升，常见原因是 Kafka 认为“心跳超时”——不是网络问题，而是你的消息处理逻辑阻塞了心跳发送。
排查重点：
- 把
config.Consumer.Group.Session.Timeout从默认 10s 改成 30s（sarama）或GroupSessionTimeoutMs: 30000（kafka-go） - 确保
Heartbeat.Interval≤ Session.Timeout / 3（如设 10s），且处理单条消息时间远小于该值 - 别在
ConsumeClaim循环里直接写 DB 或调 HTTP，用go process(msg)异步分发，否则心跳发不出
如果仍堆积，检查 config.ChannelBufferSize（sarama）是否太小，缓冲区满后新消息会被丢弃而非排队。
Offset 提交不及时？自动提交不是万能的
设 config.Consumer.Offsets.AutoCommit.Enable = true 看似省事，但一旦消费者 crash，最后一批未提交 offset 的消息就会重复消费——尤其当处理逻辑含副作用（如扣库存）时很危险。
更稳的做法：
- 关掉自动提交：
config.Consumer.Offsets.AutoCommit.Enable = false - 在消息处理成功后，**手动调用
markOffset（sarama）或CommitMessages（kafka-go）** - 注意：kafka-go 的
CommitMessages必须传入当前 reader 实例，传错 reader 会导致 offset 提交到别的 group
真正难的是“处理成功”的定义：DB 写入成功但下游回调失败，算不算？这得结合业务设计幂等键，而不是依赖 Kafka 自动机制。
配置不是贴完就完的事，每次改 session.timeout.ms 或 RequiredAcks 都要压测验证；消息体里漏了 trace_id，出问题时你连日志都串不起来。
