kafka-go.Reader比sarama.ConsumerGroup更可靠，因其天然按partition分片、无状态、不依赖goroutine协调，避免rebalance卡死和负载倾斜；必须调优MinBytes、MaxWait、CommitInterval、PartitionWatchInterval四项配置，并显式设置MaxBytes和StartOffset。
用 kafka-go.Reader 替代 sarama.ConsumerGroup 处理流数据
流式消费场景下，kafka-go.Reader 比 sarama.ConsumerGroup 更可靠。它天然按 partition 分片、无状态、不依赖 goroutine 生命周期协调，避免 rebalance 卡死和 CPU/I/O 倾斜。
常见错误是沿用 sarama 的“启动 consumer group + 实现 handler”惯性思维：一旦 Setup() 里做数据库连接或 HTTP 初始化，整个 rebalance 就阻塞，消息立刻停摆。
-
kafka-go.Reader每个实例只读一个 partition，配合PartitionWatchInterval可平滑响应扩容 - 不需要手动调度 worker，也不用担心单 consumer 被分配多个 partition 导致负载不均
-
ReadMessage返回值直接带Offset和Partition，业务逻辑与位点提交可精确对齐
必须调优的 4 个 Reader 配置项
默认配置只适合本地调试，生产环境不改必出问题：小流量下 MinBytes=10240 会导致消息延迟几百毫秒才触发读取；不设 CommitInterval 则依赖 ReadMessage 成功后自动提交，panic 时 offset 就丢了。
-
MinBytes: 1——强制最小读取字节数为 1，避免低频消息积压 -
MaxWait: 100 * time.Millisecond——批处理等待上限，平衡吞吐与端到端延迟 -
CommitInterval: 1 * time.Second——显式控制提交频率，防止 panic 时 offset 丢失 -
PartitionWatchInterval: 30 * time.Second——动态扩缩容场景下降低 rebalance 频率，避免抖动
别漏掉 MaxBytes: 1048576（1MB）和 StartOffset（流式处理通常设为 kafka.FirstOffset 或 kafka.LastOffset）。
立即学习“go语言免费学习笔记（深入）”；
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
实现 At-Least-Once + 幂等消费的关键动作
Kafka 本身不支持 Go 客户端实现端到端 Exactly-Once。能落地的是“At-Least-Once + 幂等消费”，核心是把业务处理与 offset 存储放在同一事务边界内。
- 禁用 Kafka 自动提交：
AutoCommit: true在流式 pipeline 中极其危险，尤其有缓存聚合、窗口计算等中间状态时 - 业务逻辑成功后，再将 offset 写入外部存储（如 PostgreSQL 表或 Redis），并用数据库事务包裹两者
- 禁止在 handler 里直接调用
session.Commit()（sarama）或依赖ReadMessage自动提交（kafka-go） - 消费 goroutine 内部必须
recoverpanic，否则整个 loop 退出，后续消息全卡住
缓冲 channel 大小不是越大越安全
缓冲不是用来“兜底”的，而是要和下游处理能力对齐。比如 Kafka 消费端每秒拉 500 条、单条平均耗时 8ms，则理论积压上限是 4 条，make(chan []byte, 8) 就够用（留一倍余量）。
设成 1000 看似保险，实则掩盖瓶颈，OOM 前只会默默积压旧数据、丢掉新事件。
- 无缓冲
chan：适合强顺序+低延迟场景，写入即阻塞，天然限速 - 有缓冲
chan：务必配select { case ch 或带超时的 <code>select { case ch - 别用
chan []byte直接传大 payload；先传指针或 ID，再异步加载，避免频繁堆分配
真正容易被忽略的是：流处理中 offset 提交时机和业务完成的耦合粒度——它不取决于 Kafka 配置，而取决于你是否把 offset 写入和业务结果落库放在同一个事务里。
