acks=all 和 enable.idempotence=true 必须同时开启：前者确保 ISR 全部落盘防丢失，后者配合 max.in.flight.requests.per.connection=1 和重试机制防重复；单独启用任一参数均无法保证 Exactly-Once 语义。
为什么 acks=all 和 enable.idempotence=true 必须同时开
单独设 acks=all 只防 Broker 丢消息，但不防生产者网络闪断后重发导致的重复；单独开 enable.idempotence=true 则无法保证写入成功——它依赖 max.in.flight.requests.per.connection=1 和序列号机制，若 acks=1，Leader 写完就返回，follower 同步失败时消息仍会丢失。
acks=all 要求 ISR 全部落盘才确认，必须配合 Broker 端 min.insync.replicas=2 才真正起效；enable.idempotence=true 隐式设置 retries 为极大值，并强制 max.in.flight.requests.per.connection=1，避免乱序破坏幂等性。不要手动设 retries=0 或很小值——幂等性依赖重试完成去重，禁用重试等于废掉幂等。
使用 confluent-kafka-go 时，enable.idempotence 必须在 ConfigMap 初始化时声明，运行时无法动态开启。
消费者不能靠 auto.commit，必须手动同步提交 offset
默认 enable.auto.commit=true 是最大陷阱：它按固定间隔（如 auto.commit.interval.ms=5000）提交 offset，不管业务逻辑是否执行完。HTTP handler 中调用 consumer.Commit() 前 panic，或处理耗时超过间隔，都会导致 offset 提前提交、消息丢失。
立即学习“go语言免费学习笔记（深入）”；
务必设 enable.auto.commit=false，并在业务逻辑成功后立即调用 consumer.CommitMessage(ctx, msg) 或 consumer.CommitOffsets(ctx, offsets)：
-
commitSync保证提交结果可知（失败可重试），适合强一致性场景 -
commitAsync仅适用于允许少量重复的场景 - 不要在 goroutine 里异步 commit——若 consumer 关闭或进程退出，该 goroutine 可能被直接终止，offset 永远不提交
- 如果业务处理涉及数据库写入，
commit offset应放在事务tx.Commit()之后，否则可能造成“消息已确认但 DB 写失败”的不一致
用 kafka-go 实现带退避的重试 + 手动 offset 控制
kafka-go 的 Reader 默认不自动提交 offset，只调 reader.ReadMessage(ctx) 就结束，下次启动会从上次提交的位置继续读——而那个位置可能是几小时前的。
正确做法是：在业务逻辑执行成功后，立即提交当前 message 的 offset：
msg, err := reader.ReadMessage(ctx)
if err != nil {
return err
}
// 处理业务逻辑
if err := process(msg.Value); err != nil {
return err
}
// ✅ 成功后提交 offset
if err := reader.CommitMessages(ctx, msg); err != nil {
log.Printf("commit failed: %v", err)
return err
}重试必须带退避，Kafka broker 临时不可用很常见。建议用指数退避（如 time.Second * 2^retry），最多 3–5 次；失败后不要直接跳过，应记录错误并进入死信队列（DLQ）或本地重试队列。
避免批量提交（如 accumulate 10 条再 commit）：增加重复消费概率，且故障时回溯困难；也不要调大 reader.Config().MaxWait 却不相应调高 session.timeout.ms，否则触发 rebalance。
本地事务表才是最终一致性兜底，Kafka 事务不是银弹
哪怕开了 TransactionalID，只要业务逻辑失败、服务崩溃、或消费者处漏写消息表，照样丢消息。Kafka 事务只解决跨分区原子写入，掩盖不了更常见的丢消息路径：本地业务失败、消费者重复、消息表漏写。
真正的可靠性来自三件事：生产者配置底线（acks=all + enable.idempotence=true）、消费者提交时机可控（禁用 auto.commit + 手动 commitSync + 事务后置）、以及业务与消息的耦合方式（例如把消息写入与 DB 操作置于同一事务，或用本地事务表做最终一致性校验）。
最容易被忽略的是：消费者重启时，若未成功提交上一条 offset，就会从旧位置重拉——这不是 Kafka 的 bug，而是设计使然；你得靠日志、监控和 DLQ 机制来发现并补救，而不是指望某一个开关自动兜底。
