Iris + kafka-go 更稳，因 kafka-go.Reader 用 context 控制生命周期、自动分片、错误重试、显式提交 offset，而 sarama 在无管理框架中易致卡死或重复消费；生产需调 MinBytes、MaxWait、CommitInterval 等五参数。
直接用 kafka-go，别碰 sarama —— Iris 是轻量 HTTP 框架，不提供消费者生命周期管理，而 sarama.ConsumerGroup 的 Setup/Cleanup 阻塞、Errors 通道漏读、offset 提交易丢等问题，在 Iris 这类无内置 consumer 管理的框架里会直接暴露为进程卡死或重复消费。
为什么 Iris + kafka-go 是更稳的选择
Iris 本身不封装消息消费逻辑，只负责 HTTP 路由和中间件。这意味着你得自己启 goroutine 做消费，而 kafka-go.Reader 天然适配这种模式：
-
Reader生命周期靠context.Context控制，可随 Iris 应用启动/关闭同步启停 - 按 partition 自动分片，不用自己写 worker 调度器
-
ReadMessage返回 error 后默认重试（可配MaxAttempts），sarama的错误要手动从Errors()通道取，漏读就静默失败 -
CommitInterval显式控制提交节奏，panic 时不会丢 offset；sarama依赖session.CommitOffsets()，一忘调就重复消费
kafka-go Reader 必须显式配置的五项参数
默认配置只适合本地 demo，上生产必调，否则消息积压、延迟飙升、位点错乱：
-
MinBytes: 1：避免小流量下等满 10KB 才返回，延迟可能达秒级 -
MaxWait: 100 * time.Millisecond：平衡实时性与网络开销，设太大会拖慢流处理，设太小触发频繁拉取 -
CommitInterval: 1 * time.Second：必须设！否则依赖ReadMessage自动提交，handler panic 就丢 offset -
PartitionWatchInterval: 30 * time.Second：防止 broker 重启或 topic 扩容时每秒 rebalance 一次 -
StartOffset显式设为kafka.FirstOffset或kafka.LastOffset，别信默认值（它可能是kafka.OffsetNewest，跳过历史消息）
在 Iris 启动/关闭时正确管理 Reader 生命周期
Iris 没有类似 Kratos 的 App.Start / App.Stop 钩子，得靠 iris.RegisterOnInterrupt 和手动 defer：
立即学习“go语言免费学习笔记（深入）”；
- 启动时用
go func() { for { ... reader.ReadMessage(ctx) } }()启消费 goroutine - 注册中断信号：
iris.RegisterOnInterrupt(func() { reader.Close() })，确保 Ctrl+C 或 systemd stop 时能 clean shutdown - 别在 handler 里直接调
reader.ReadMessage—— 它是阻塞的，会卡住整个 HTTP worker - 若需业务层幂等，用
msg.Key或msg.Headers中的"idempotency-id"做去重，不是靠客户端自动保证
Exactly-Once 在 Iris + Kafka 场景中根本不存在
Kafka 的 Exactly-Once 语义需要 broker 端事务协调器 + 幂等 producer + transactional consumer 全链路支持，kafka-go 和 sarama 都不支持 read_committed + isolation.level=transactional 的 consumer 事务读。实际能落地的只有：
- At-Least-Once 投递（靠
RequiredAcks: kafka.RequiredAcksAll+ 重试） - 业务层幂等（用 msg.Key 或自定义 header 标识唯一业务事件）
- 消费逻辑与 offset 提交不在同一事务边界内——Iris 没有 DB 事务上下文自动传播，必须自己把 DB 写入和
reader.CommitMessages放进同一个 error 判断分支
真正难的不是连上 Kafka，而是当 consumer panic 后恢复、broker 暂时不可用、或流量突增时，你的 CommitInterval 是否还准、消息是否仍在预期顺序里、下游会不会被同一条消息打穿——这些细节全藏在配置和错误处理路径里。
