单个goroutine消费单Partition是硬性要求，因跨goroutine并发读同一Partition会破坏消息顺序且无法通过加锁修复；Kafka客户端不提供跨goroutine的offset同步机制，导致重复、跳过或乱序处理。
单个 goroutine 消费一个 Partition 是硬性要求，不是优化建议——跨 goroutine 并发读同一 Partition 会直接破坏顺序，且无法靠加锁修复。
为什么不能用多个 goroutine 同时读同一个 Partition
Partition 内消息顺序由 Broker 的 WAL 和 Offset 单调递增保证，但 Kafka 客户端（如 kafka-go 或 sarama）不提供跨 goroutine 的 offset 同步机制。一旦两个 goroutine 同时调用 FetchMessage() 或 ReadMessage()，它们可能各自拿到不同 offset 的消息，后续处理完全不可控。
- 现象：同一批消息被重复处理、跳过、乱序打印（如先处理 offset=102，再处理 offset=100）
- 根本原因：offset 提交是 per-goroutine 独立进行的，
CommitOffset(102)和CommitOffset(100)无因果关系，Broker 只认最后一次提交 - 陷阱：哪怕你用 channel 把消息“转发”给 worker goroutine，只要
ReadMessage()在多个 goroutine 中并发调用，就已经违规
goroutine 正确分工方式：按 Partition 分配，而非按消息分发
真正可扩展的并发模型是让每个 Partition 绑定唯一 goroutine，再通过消费者组（GroupID）自动将不同 Partition 分配给不同机器或进程。Go 层面只做“守好自己那块分区”的事。
-
kafka-go的Reader默认就是单 goroutine 消费单 Partition，别在ReadMessage()后立刻起新 goroutine 处理消息 - 若需并行处理业务逻辑（如 HTTP 调用、DB 写入），应把消息塞进带缓冲的 worker pool channel，由固定数量 goroutine 消费，但必须确保：消息入池前已提交 offset，或至少记录当前处理中的 offset 范围
- 手动分配 Partition 时（不用 GroupID），务必检查
reader.Config.Partition是否唯一，避免两个Reader实例配置了相同Topic+Partition
Consumer Group 下的 goroutine 数量怎么定
消费者实例数（即运行该 Go 程序的进程数）应 ≤ Topic 总 Partition 数；每个实例内部，goroutine 数 = 它被分配到的 Partition 数。这是 Kafka 原生负载均衡的边界，越界只会造成空转。
立即学习“go语言免费学习笔记（深入）”；
- 例如 Topic 有 12 个 Partition，部署 4 个消费者实例 → 每个实例平均分到 3 个 Partition → 每个实例启动 3 个 goroutine，各守一区
- 若部署 20 个实例，只有 12 个能分到 Partition，其余 8 个 idle —— 这不报错，但浪费资源
- 不要为了“看起来更并发”而强行在一个实例里启动 12 个 goroutine 去轮询所有 Partition：这绕过了 Group 协议，导致 rebalance 失效、offset 提交混乱
容易被忽略的 context 和超时控制
ReadMessage(context.Background()) 看似简单，但没设 timeout 会导致 goroutine 卡死在 broker 不可用或网络抖动时，整个 Partition 消费停滞。
- 必须传带 deadline 的 context：
ctx, _ := context.WithTimeout(context.Background(), 30*time.Second) - 错误处理不能只判
err != nil：对kafka.ErrUnknownTopicOrPartition应触发client.RefreshMetadata()，对context.DeadlineExceeded可重试，对io.EOF通常表示连接断开需重建 Reader - 别依赖
CommitInterval自动提交：高吞吐场景下，它可能积压数百条未提交消息；建议每处理 N 条（如 50）或每秒主动调一次r.CommitMessages(ctx, m)
真正的协同不在 goroutine 数量，而在 Partition 边界是否清晰、offset 提交是否及时、context 是否可控——这些点漏掉任意一个，再多的 goroutine 也只会把问题放大。
