groupid必须显式设置且不能为空，因为它是kafka消费者组机制的唯一标识，缺失时客户端无法加入组、触发再平衡、共享分区分配，会被coordinator拒绝，导致重复消费或阻塞；空值将抛出configexception。
为什么 GroupID 必须显式设置，且不能为空？
因为 Kafka 的消费者组机制完全依赖 GroupID 识别归属关系——没有它，客户端就不是“组内成员”，而是独立消费者，会绕过再平衡、无法共享分区分配逻辑，甚至被 coordinator 拒绝加入组。
常见错误现象：ReadMessage 返回 context.DeadlineExceeded 或持续阻塞，日志里出现 GROUP_COORDINATOR_NOT_AVAILABLE；或看似能消费，但多个实例实际在重复拉取同一分区（即没形成组）。
-
GroupID是字符串标识，必须全局唯一且稳定：上线后不要随意变更，否则会触发全量再平衡，历史 offset 可能丢失 - 测试环境建议用带环境前缀的值，比如
"dev-order-processor"，避免和线上冲突 - 若想让单个消费者“独占”主题（不参与组协调），可不设
GroupID，改用Partition+Offset手动指定，但失去自动负载均衡能力
CommitInterval 设为 0 和设为 1s 的实际行为差异
这直接决定偏移量提交时机，进而影响“至少一次”还是“最多一次”语义。
设为 0 表示同步提交：每次 ReadMessage 成功后立即发请求到 __consumer_offsets，延迟高、吞吐低，但崩溃后重连几乎不会重复消费；设为 1s（或其它正数）表示异步批量提交：每秒汇总一次 offset 并提交，吞吐高，但若消费者在两次提交之间宕机，重启后会从上次提交位置重拉，导致少量重复。
- 电商订单这类强一致性场景，建议先设
0，等流程跑稳再调大 - 日志采集类场景可设
time.Second或更大，容忍短时重复 - 注意：即使设了
CommitInterval，手动调用r.CommitMessages仍会立刻触发提交，不受间隔限制
再平衡期间消息消费为什么会暂停？
因为 Kafka 要求组内所有消费者在新分区分配完成前停止拉取——这是协议强制行为，不是库实现缺陷。kafka-go 的 Reader 在收到 REBALANCE_IN_PROGRESS 响应后会主动阻塞 ReadMessage，直到分配完成。
容易踩的坑：把再平衡误判为网络故障，在超时后直接退出循环；或在处理消息时做了耗时操作（如 HTTP 请求、数据库写入），导致心跳超时，又触发新一轮再平衡，陷入恶性循环。
- 确保
session.timeout.ms（通过kafka.NewReader的底层配置传入）大于业务单条消息处理时间，建议至少设为 10s - 避免在
ReadMessage后的主循环里做阻塞操作；复杂逻辑扔进 goroutine + channel 处理 - 监听
reader.Errors()可捕获再平衡事件（如"rebalance in progress"），但无需干预，kafka-go 内部已处理
为什么用 kafka-go 而不是 sarama 实现消费者组？
核心区别在抽象层级：kafka-go 把消费者组封装成开箱即用的 Reader，隐藏了 JoinGroup、SyncGroup、心跳维持等细节；sarama 则暴露了 ConsumerGroup 接口，需要手动管理状态机、处理 Setup/Cleanup 回调、自己实现 offset 提交逻辑。
如果你只需要“拉消息→处理→提交”，kafka-go 更省心；但若需深度定制分配策略（比如按 key 哈希固定到某 consumer）、或与现有 sarama Producer 共享连接池，则选 sarama。
-
kafka-go的Reader不支持自定义分区分配器（只能用内置的 range/roundrobin），而sarama的ConsumerGroup允许传入protocol.GroupMemberAssignment -
kafka-go默认使用RoundRobin策略，对 topic 分区数变化更友好；sarama默认是Range，在分区数增加时容易导致分配不均 - 两者都依赖 broker 版本兼容性，2.8+ 推荐用
kafka-go，旧集群（sarama 版本
JoinGroup 请求、__consumer_offsets 里 offset 是否连续更新、以及你的 goroutine 是否真在并发处理而非串行堵着。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
