因为recover()只对当前goroutine有效且须在panic同栈中defer调用，而Kafka客户端在内部goroutine中调用用户handler，故必须在handler函数内单独defer recover()，而非外层循环。
为什么Kafka消费者循环里不能直接 defer recover()
Go 的 recover() 只对当前 goroutine 有效，且必须在 panic() 发生的同一函数调用栈中、且在 defer 里调用才起作用。Kafka 消费者（比如用 sarama.ConsumerGroup 或 segmentio/kafka-go）通常把消息处理逻辑封装进回调函数（如 ConsumeClaim 或 Handler），而这些回调是被库内部 goroutine 调用的——你无法在那个 goroutine 里插自己的 defer。
正确做法：在消息处理函数内部做 recover
真正的 panic 往往来自你写的业务逻辑（比如解码 JSON 失败、空指针访问、除零等），所以必须把 recover() 放进你实际控制的 handler 函数里，而不是包在 ConsumerGroup.Consume() 外层。
以 segmentio/kafka-go 为例：
func (h *myHandler) Consume(ctx context.Context, msg kafka.Message) error {
defer func() {
if r := recover(); r != nil {
log.Printf("panic in message handler: %v, key=%s, offset=%d", r, string(msg.Key), msg.Offset)
// 注意：这里不能 return error，因为 Consume 签名要求返回 error；但 recover 后应避免继续处理
// 建议记录后主动 return nil 或特定 error，取决于你是否想跳过该消息
}
}()
// 你的实际处理逻辑，可能 panic
var data MyStruct
if err := json.Unmarshal(msg.Value, &data); err != nil {
panic("invalid json") // 示例：故意触发 panic
}
// ... 其他业务代码
return nil
}
- 必须在每个可能 panic 的 handler 函数里单独加
defer recover()，不能只在主循环外加一次 - recover 后不要继续执行后续逻辑，尤其涉及状态变更或副作用时；建议日志后立即 return
- 注意：
recover()不捕获 runtime error（如 stack overflow），只捕获显式panic()和部分运行时 panic（如 nil pointer dereference）
用 sarama.ConsumerGroup 时怎么加 recover
sarama 的 ConsumerGroupHandler 接口要求实现 ConsumeClaim 方法，这个方法会被库启动的多个 goroutine 并发调用。同样，recover 必须落在你写的 ConsumeClaim 内部，而不是外部启动逻辑里。
示例：
func (h *myHandler) ConsumeClaim(session sarama.ConsumerGroupSession, claim sarama.ConsumerGroupClaim) error {
for msg := range claim.Messages() {
func() {
defer func() {
if r := recover(); r != nil {
log.Printf("panic in ConsumeClaim: %v, topic=%s, partition=%d, offset=%d",
r, msg.Topic, msg.Partition, msg.Offset)
}
}()
h.handleMessage(msg) // 你自己的处理函数，里面可能 panic
session.MarkMessage(msg, "") // 成功才标记
}()
}
return nil
}
- 这里用了匿名函数包裹单条消息处理，确保每次 panic 都被独立捕获，不影响其他消息
- 如果
handleMessagepanic，session.MarkMessage就不会执行，Kafka 会重投该消息（符合 at-least-once 语义） - 不要在
ConsumeClaim函数顶部 defer recover —— 那样只能捕获该函数自身 panic，捕不到handleMessage里的
recover 之后要不要重试？怎么避免死循环
recover 只是防止崩溃，不代表问题已解决。如果同一条消息反复触发 panic（比如格式永远不对），不加控制就会无限重试、刷爆日志、拖垮 consumer。
- 在 recover 后，建议将出错消息写入死信队列（DLQ）Topic，而不是原地重试
- 或者加简单计数：用
msg.Headers或外部存储记录失败次数，超阈值就丢弃或转 DLQ - 避免在 handler 里做阻塞操作（如长时间 HTTP 调用），否则 panic 前可能已卡住 session，导致 rebalance 异常
- 注意：某些 Kafka 客户端（如 older sarama）在 handler panic 后会终止整个
Consume循环；recover 是唯一能保活的方式
真正难的不是加 recover，而是判断 panic 后该 commit 还是该跳过、该告警还是该降级——这些得结合你的业务幂等性和数据一致性要求来定。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
