消费者收不到消息主因是sarama.config默认值不当：需开启consumer.return.errors、设consumer.offsets.initial为offsetoldest/offsetnewest、调大net.dialtimeout/readtimeout。
Go 里用 sarama 连 Kafka，为什么消费者老是收不到消息？
绝大多数情况不是 Kafka 配置问题，而是 sarama.Config 默认值太保守，尤其 Consumer.Return.Errors 关着、Consumer.Offsets.Initial 没设对、或者 Net.DialTimeout 太短导致连接被静默丢弃。
-
Consumer.Return.Errors必须设为true，否则消费异常（如 offset 越界、分区重平衡失败）完全不报错，只默默跳过 - 新消费者组首次启动时，
Consumer.Offsets.Initial要明确设成sarama.OffsetOldest或sarama.OffsetNewest；默认值是0，但 Kafka 会按 group.id 查 last committed offset，查不到就触发UnknownMemberId错误并退订 - 本地开发连 Docker Kafka 时，
Net.DialTimeout和Net.ReadTimeout建议至少10 * time.Second，否则容器网络抖动直接断连不重试 - 别用
sarama.SyncProducer做事件发布——它阻塞、难超时控制、不支持批量；改用sarama.AsyncProducer，监听Successes()和Errors()channel 处理结果
Go 微服务中如何安全地把事件结构体序列化进 Kafka？
直接 json.Marshal 结构体发到 Kafka 看似简单，但版本演进时字段增删会导致消费者 panic 或静默丢数据。核心矛盾是：Kafka 不管 schema，而 Go 的 struct 是强类型。
- 永远在消息体头部加一个
version字段（比如{"v": "1.2", "data": {...}}），消费者按 version 分支解析，避免强转失败 - 避免用
time.Time字段直塞 JSON——时区、格式、零值行为在不同 Go 版本/消费者语言里不一致；统一转成 RFC3339 字符串或 Unix 毫秒整数 - 如果用 Protobuf，别手写
Marshal；用gogoproto+gofast插件生成代码，并在 producer/consumer 两端共用同一份.proto文件和生成逻辑 - Kafka topic 名建议带 service 名和 domain event 名，比如
order-service.order-created.v1，别用orders这种模糊名——方便权限隔离、监控追踪、schema 管理
事件驱动下，Go 服务怎么保证“处理一次且仅一次”？
严格意义上的 Exactly-Once 在分布式系统里本质是妥协出来的。Kafka 0.11+ 提供事务 API，但 Go 的 sarama 目前（v1.35）只支持 AsyncProducer 的幂等模式（Producer.Idempotent = true），不支持跨 topic/跨 producer 的事务。所以实际方案得组合设计。
- 开启
Producer.Idempotent = true+Producer.RequiredAcks = sarama.WaitForAll，能防网络重传导致的重复写入 - 消费者侧必须自己做幂等：用业务主键（如
order_id）+ 事件 ID（如event_id或timestamp_ms + sequence）构造唯一索引，入库前先SELECT判断是否存在 - 别依赖 Kafka offset 提交时机来控制处理边界——重平衡时 offset 可能提前提交，导致消息被跳过；应采用“处理完成 → 写 DB → 提交 offset”三步，且 DB 写入和 offset 提交放在同一个事务（如用 pgx + Kafka offset 存 PG 表）
- 如果事件要触发下游 HTTP 调用，记得加去重请求头（如
X-Event-ID），让下游也做幂等判断
为什么用 Go 写 Kafka 消费者，CPU 占用突然飙升到 300%？
不是 GC 问题，大概率是 sarama.ConsumerGroup 实现里一个隐蔽行为：当 consumer group 心跳失败（比如 GC STW 超过 session.timeout.ms），它会不断发起 JoinGroup 请求，而每次失败都触发全量 metadata refresh，疯狂轮询所有 broker。
立即学习“go语言免费学习笔记（深入）”；
- 调大
Config.Consumer.Group.Session.Timeout（建议 ≥ 45s），同时确保Config.Consumer.Group.Heartbeat.Interval≤ SessionTimeout / 3 - 别在
ConsumeClaim回调里做耗时操作（如 HTTP 请求、大文件 IO）——它运行在单个 goroutine 里，阻塞会导致 heartbeat 发不出，触发 rebalance - 每个
topic-partition对应一个claim，但默认 sarama 不限制并发处理数；用semaphore或带缓冲 channel 控制最大并发 claim 数，避免 goroutine 泛滥 - 监控
sarama:client/metadata/fetch/errors和sarama:client/heartbeat/failures这两个指标，它们比 CPU 更早暴露问题
真正麻烦的是跨服务的事件 Schema 演进和消费者升级节奏不一致——没强制校验、没灰度通道、没 dead-letter topic 的架构，撑不过三个月。
