offset 表示“下一条该从哪开始拉取”，非“已消费哪条”；每个分区独立维护递增序列，position 是下次 poll() 起始位，committed offset 是已确认处理完成的最后位置；提交 offset=5 意味着 0~4 已处理完毕，下次从 5 开始。
偏移量（Offset）是 Kafka 消费者最核心的状态标识，它不是“已消费了哪条”，而是“下一条该从哪开始拉取”。理解这一点，才能避免重复消费或数据丢失。
Offset 的本质与关键区别
每个分区独立维护一串从 0 开始递增的 Offset 序列。消费者有两个关键位置：
-
position（当前位移）：即
consumer.position(partition)返回的值，代表“下次 poll() 将拉取的消息的 Offset”，也就是“下一条该读哪条”； -
committed offset（已提交位移）：即
consumer.committed(partition)返回的值，代表 Kafka 记住的、你“确认已处理完成”的最后位置，重启或再平衡后就从这里恢复。
注意：提交的 offset 值必须是 position 的前一个值（即已成功处理的最后一条消息的 offset），Kafka 内部按“下一条起始位置”来存储和使用 —— 所以提交 offset=5，实际表示 0~4 已处理完毕，下次从 5 开始拉。
自动提交：简单但有风险
默认开启（enable.auto.commit=true），每 auto.commit.interval.ms（默认 5 秒）触发一次，提交的是当前所有已拉取但尚未被新轮询覆盖的最高 offset。
- 优点：零配置、开发快，适合测试或对数据准确性要求不高的场景；
- 缺点：无法保证“处理完再提交”，若消息处理失败或消费者崩溃在提交前，就会丢失数据；若处理成功但提交延迟，再平衡后可能重复消费最近几条。
手动提交：可控但需设计
关闭自动提交（enable.auto.commit=false），由业务代码决定何时调用 commitSync() 或 commitAsync()。
- 同步提交（commitSync）：阻塞直到 Broker 确认，确保提交成功，但会拖慢吞吐；适合对一致性要求极高、能接受性能折损的环节；
- 异步提交（commitAsync）：立即返回，后台发请求，不保证一定成功；适合高吞吐场景，但需配合回调处理失败（如记录日志、降级重试）；
- 组合策略：常用“异步提交 + 定期同步兜底”，例如每处理 N 条异步提交一次，每次 poll() 前做一次同步提交，兼顾性能与可靠性。
提交时机决定数据语义
Offset 提交不是技术动作，而是业务承诺 —— 表示“至此为止的所有消息，我已成功处理”。因此必须严格遵循“先处理、再提交”顺序：
- 批量处理时，应提交最后一条成功处理消息的 offset，而不是本轮拉取的最大 offset；
- 多线程消费同一分区时，不能直接用
commitSync()，需自行维护线程安全的 offset 记录，再统一提交； - 若处理逻辑含外部依赖（如写 DB 失败），必须回滚或补偿，否则提前提交会导致数据不一致。
偏移量管理没有银弹，关键是把提交行为绑定到真实业务完成点，而不是消息抵达点。
