Kafka auto.offset.reset 怎么配置？earliest 和 latest 有什么区别？
面试怎么回答
auto.offset.reset 只在 Group 没有初始 Offset，或原 Offset 因 Retention 等原因失效时生效。earliest 从当前仍保留的最早位置开始，latest 从日志末尾等待新消息，none 直接报错。它不会覆盖有效的已提交 Offset，因此历史重放要用新 Group、管理工具重置或显式 seek。生产选择还要结合是否允许漏历史、下游幂等和缺口补偿。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
一个新 Consumer Group 上线后，程序运行正常，却一直看不到 Topic 里原来已经存在的消息。
另一个任务改成 earliest 重启，结果也没有从头重新消费。
这两个现象，都和 auto.offset.reset 的生效条件有关。
先说核心结论：auto.offset.reset 只在没有已提交 Offset，或者已提交 Offset 已经失效时生效，不会覆盖一个仍然有效的已提交 Offset。
earliest、latest 和 none 分别做什么？
earliest
从当前仍然保留的最早 Offset 开始消费。
这里的“最早”不是 Topic 创建以来的第一条。如果旧消息已经因为 Retention 被删除，Consumer 只能从当前日志起点开始。
latest
从当前日志末尾开始，等待消费之后新写入的消息。Topic 中已经存在的历史消息通常不会被这个新 Group 消费。
none
当找不到有效 Offset 时直接抛出异常，让任务停止并要求人工判断，而不是自动选择起点。
Kafka 新版本还提供按时间跨度回退的 by_duration 选项，但是否可用要以实际客户端版本为准。
为什么改成 earliest 也没有重放？
因为 Consumer Group 已经有一个有效的已提交 Offset。
Kafka 会继续从这个 Offset 消费，不会因为配置改成 earliest 就回到日志起点。
如果业务确实需要重放历史数据，通常要：
- 使用新的 Consumer Group
- 停止原 Group 后，用管理工具重置已提交 Offset
- 在应用中明确
seek到目标位置
无论哪种方式，都要先确认重放范围、下游幂等能力和任务是否已经停止，避免一边消费一边改 Offset。
怎么选择？
历史数据必须补齐
例如账务、订单、状态变更等不能漏数的链路，新 Group 通常更偏向 earliest，同时保证下游可幂等。
只关心上线后的新事件
例如临时监控或实时提示，可以选择 latest，但要明确上线前数据不会被处理。
不允许系统擅自决定
关键链路可以选择 none，让 Offset 缺失或越界直接暴露，再由值班人员确认恢复位置。
一个容易忽略的风险
Consumer 长时间停机后，原来提交的 Offset 可能已经早于当前日志起点。
如果此时配置 latest，任务恢复后可能直接跳到末尾，历史缺口没有被处理；如果使用 earliest，也只能从当前仍保留的最早消息开始，已经被删除的数据无法通过 Kafka 自动找回。
所以生产里不能只看任务“恢复成功”，还要核对：
- Offset 为什么失效
- 实际从哪个位置恢复
- 缺口时间段是否仍在 Kafka
- 下游数据是否需要补数和对账