我先给结论，再说明它在项目里解决什么问题。理解分区分配、消费位点、再均衡和重复消费。同一个消费者组内，一个分区在同一时刻只会分配给一个消费者；增加消费者数量可以提高并行度，但超过分区数的消费者会处于空闲状态。

核心机制我会按一次真实执行过程来讲。沿着「消费者加入组 → 协调器完成分区分配 → 按 offset 拉取批次 → 处理并提交位点 → 成员变化触发再均衡」观察输入、状态与输出，这些阶段都可以从日志、指标或源码里验证。 消费者加入组 group.id 标识逻辑消费订阅，同组内一个分区在稳定时期只分配给一个消费者。 协调器完成分区分配 Coordinator 与分区分配策略决定成员和分区映射，成员数超过分区数会有空闲消费者。

实现细节只抓关键入口，不会整段背源码。ConsumerGroupCoordinator：组状态与位点。 kafka-consumer-groups.sh：成员、分配和 Lag。 我会先确认请求实际走到了哪条路径，再用运行数据验证，不会只看类名或配置猜测。

放到生产使用时，我会关注参数和验证数据。滚动发布与扩缩容，比较 eager/cooperative 的停顿和分区迁移。 固定输入和基线 先在没有故障注入的环境执行上述配置，固定数据规模、并发度、运行时版本和预热时间。以「rebalance 次数」为主基线，记录值应满足「记录分区基线」；同时保存 Consumer Lag、rebalance 次数与时长，使后续变化能够回到同一时间轴比较。

最后补充常见误区和使用边界。频繁滚动发布让组不断再均衡，消费者停止处理并重复转移分区。使用静态成员、协作式粘性分配与更平缓发布后，分区所有权稳定，Lag 才下降。 消费者数超过分区数期待继续扩吞吐：Consumer Lag：CooperativeStickyAssignor。 处理未完成就自动提交：rebalance 次数与时长：static membership。 方案：更适合的场景：主要收益：代价与边界。 Range/RoundRobin：简单订阅与分区较均匀：易理解：多 Topic 或异构分区可能倾斜。 Sticky：希望减少迁移并保持均衡：再均衡后缓存局部性较好：仍可能是 eager 全量撤销。 CooperativeSticky：大组和频繁扩缩容：增量再均衡、停顿小：客户端与协议版本需兼容。