kafka-go消费者收不到消息的常见原因：groupid为空导致从最新offset拉取、topic名称大小写不匹配或不存在、broker地址不可达；kafka静默跳过而非报错。
Go 本身不提供 Kafka 原生支持，必须依赖第三方客户端库；sarama 功能全但 API 复杂易出错，segmentio/kafka-go 更轻量、API 直观、内置重试与上下文取消，日常事件驱动场景优先选它。
用 kafka.NewReader 消费事件时为什么收不到消息？
常见原因不是配置错，而是消费者组（group.id）和主题（topic）没对上，或 broker 地址不可达。Kafka 不会报错，只会静默跳过。
-
brokers必须是可连通的 broker 列表（如["localhost:9092"]），不能只写一个且该节点恰好下线 -
groupID必须非空，否则kafka.NewReader会退化为“自动 offset 重置”模式，每次启动都从最新 offset 拉——旧消息永远收不到 -
topic名称需严格匹配（区分大小写），且该 topic 必须已存在（kafka-go不自动创建 topic） - 检查
net.Dial日志：加logger: kafka.LoggerFunc(...)可看到底层连接状态
kafka.Writer 发送失败后要不要手动重试？
不用。默认配置下 kafka.Writer 已启用重试（MaxAttempts: 10），且失败时返回的 error 是重试耗尽后的最终错误。关键是要判断错误类型再决定是否丢弃或告警。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 网络类错误（如
"i/o timeout"、"connection refused"）通常可接受，重试即可 -
"kafka: invalid message"或"kafka: unknown topic or partition"属于配置/部署问题，需人工介入 - 发送前务必设置
RequiredAcks: kafka.RequiredAcksAll，避免消息写入部分副本就返回成功 - 不要在循环里反复
WriteMessages同一批数据——它内部已批量，重复调用会放大延迟
如何保证事件处理的 Exactly-Once 语义？
纯客户端做不到。Kafka 的 EOS 依赖 broker 端事务 + 生产者幂等 + 消费者 commit 位点精确控制，kafka-go 目前仅支持事务（kafka.NewTransactionalWriter），但要求 broker ≥ 0.11 且开启 transactional.id。
- 更现实的做法是业务层幂等：用消息里的
key或自定义event_id做去重（如写入 DB 前先SELECT FOR UPDATE） - 消费位点提交必须和业务处理在同一个事务中（例如用 PostgreSQL 的
pgx事务包裹db.Exec和reader.CommitOffsets） - 避免在
for { msg := reader.ReadMessage(...) }循环里直接处理——万一 panic，offset 就丢了；应先ReadMessage，再defer reader.CommitMessages(...)，再处理
真正麻烦的不是连上 Kafka，而是 offset 提交时机、错误分支的资源清理、以及跨服务事件的最终一致性边界——这些地方没日志、没监控、没补偿，上线后第一个流量高峰就会暴露。
