用kafka-go消费单分区消息最简路径是ReadMessage，它自动处理连接、fetch和offset提交，适合本地调试；但消息读取后立即提交，业务失败即丢消息，且需显式指定Partition。
用 kafka-go 消费单分区消息最简路径
不需要消费者组、不涉及重平衡时，kafka-go 的 ReadMessage 是最快上手的方式。它封装了底层连接、fetch 循环和自动 offset 提交，适合本地调试或监控类轻量场景。
但要注意：ReadMessage 会在读到消息后立即提交 offset，一旦业务处理失败（比如 panic 或网络超时），这条消息就丢了——它不提供重试或回滚能力。
- 必须显式设置
Partition字段，否则会报错partition must be specified for single-partition readers -
MinBytes和MaxBytes影响拉取延迟：设太小（如 1）会导致频繁轮询；设太大（如 100MB）可能卡住几秒才返回 - 若 Kafka broker 的
advertised.listeners配置为localhost:9092，而你的 Go 程序跑在 Docker 容器里，ReadMessage会连不上——得改成宿主机 IP 或配置 broker 正确暴露地址
FetchMessage 手动控制 offset 的真实用法
想确保“处理成功才提交”，必须用 FetchMessage。它只负责拉取消息，不自动提交，把控制权完全交给业务代码。
常见错误是调用 CommitMessages 时不传上下文或忽略返回 err，导致 offset 实际没提交，重启后重复消费。
立即学习“go语言免费学习笔记（深入）”；
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
-
CommitMessages必须在同个kafka.Reader实例上调用，不能跨 Reader 提交其他 Reader 拉到的消息 - 不要在 goroutine 里直接对
m调用CommitMessages，因为m是值拷贝，CommitMessages内部依赖原始 reader 的内部状态 - 建议用
context.WithTimeout包裹CommitMessages，避免网络抖动时卡死整个消费循环
为什么 sarama 的 ConsumerGroup 更适合生产环境
当 topic 有多个分区、需要横向扩展消费者数量时，kafka-go 原生不支持消费者组协议——你得自己实现分区分配、rebalance 通知、offset 同步等逻辑。而 sarama 的 ConsumerGroup 把这些都封装好了。
但它不是开箱即用：不调 Close() 会泄露 goroutine 和 TCP 连接，broker 日志里很快出现 Connection reset；不设 config.Consumer.Offsets.Initial，新 group 第一次启动可能从最新 offset 开始，漏掉积压消息。
- 务必在 defer 中调用
consumer.Close()，而不是只在 main 结束前调一次 - 如果要用 earliest 启动，设
config.Consumer.Offsets.Initial = sarama.OffsetOldest，别信文档里“默认从 oldest 开始”的说法——实际默认是OffsetNewest -
sarama不自动创建 topic，auto.create.topics.enable=true是 broker 配置项，生产环境通常关闭，topic 得提前由运维建好
并发消费时 goroutine 泄露和消息丢失的临界点
用 FetchMessage + goroutine 处理每条消息时，最容易踩的坑是没控并发数。1000 条消息进来就启 1000 个 goroutine，内存爆掉、Kafka broker 连接数打满、甚至触发 Linux OOM killer。
更隐蔽的问题是：goroutine 里处理失败但没 recover，panic 后该 goroutine 就静默退出，对应消息的 offset 永远不会被提交，后续所有消息都被阻塞在同一个 partition 上。
- 用带缓冲的 channel（如
semaphore := make(chan struct{}, 10)）做并发闸门，比用sync.WaitGroup更可控 - 每个 goroutine 必须包一层
defer func() { if r := recover(); r != nil { log.Printf("panic: %v", r) } }() - 别在 goroutine 里直接调
reader.CommitMessages，应把成功信号发回主 goroutine 统一提交，避免并发写 reader 内部状态
