我先给结论，再说明它在项目里解决什么问题。理解重复消费来源，并使用唯一约束、状态机和幂等键保证业务结果只生效一次。Kafka 很难保证消息永远只投递一次，工程上通常采用至少一次投递，再通过业务唯一键、数据库唯一约束、条件更新或幂等记录表，保证重复消息不会重复产生业务效果。

核心机制我会按一次真实执行过程来讲。沿着「拉取消息 → 执行业务副作用 → 记录幂等键/状态 → 提交 offset → 失败后重新投递并识别重复」观察输入、状态与输出，这些阶段都可以从日志、指标或源码里验证。 拉取消息 Kafka 默认至少一次场景下，崩溃、超时和再均衡都可能让同一 offset 再次交付。 执行业务副作用 业务处理可能写数据库、调用外部接口或发新消息，不同副作用需要各自的幂等证据。

实现细节只抓关键入口，不会整段背源码。ConsumerCoordinator：offset 提交。 数据库唯一业务键：最终副作用裁决。 我会先确认请求实际走到了哪条路径，再用运行数据验证，不会只看类名或配置猜测。

放到生产使用时，我会关注参数和验证数据。在业务提交后、offset 提交前 kill 消费者，验证重放只返回旧结果。 固定输入和基线 先在没有故障注入的环境执行上述配置，固定数据规模、并发度、运行时版本和预热时间。以「幂等冲突」为主基线，记录值应满足「记录分区基线」；同时保存 唯一冲突/幂等命中率、处理到提交耗时，使后续变化能够回到同一时间轴比较。

最后补充常见误区和使用边界。消费者先调用券系统再记录已处理标记，进程在两步之间宕机，重试再次发券。将券请求号作为下游幂等键，并在本地数据库用唯一约束记录处理状态后，跨系统两端都有防线。 用内存 Set 去重重启后失效：唯一冲突/幂等命中率：最终写唯一约束。 幂等记录和业务写不在同一事务：处理到提交耗时：记录处理中/成功状态。 方案：更适合的场景：主要收益：代价与边界。 数据库唯一约束：副作用最终落同一数据库：正确性证据强、实现直接：冲突处理与热点索引成本。 幂等状态表：多步骤业务需记录处理中/成功：状态可追踪、可补偿：表增长与清理治理。 下游幂等 API：副作用在外部系统：真正保护最终资源：依赖对方契约和保留窗口。 选型至少带上 消息速率、峰值带宽、分区数、消息大小和积压恢复时间，并用上面的量化基线验证；未知数据应明确为待测假设。