核心在于生产者配置、消费者提交时机及业务与消息耦合方式；acks=all与enable.idempotence=true必须同时启用，缺一不可，且消费者须禁用auto.commit、手动同步提交offset，并将消息写入与业务操作置于同一数据库事务中。
Go 语言集成 Kafka 实现可靠投递，核心不在“用不用事务”，而在于生产者配置、消费者提交时机、以及业务与消息的耦合方式是否经得起网络抖动和进程崩溃。事务（TransactionalID）只解决跨分区原子写入，但掩盖不了本地业务失败、消费者重复或消息表漏写等更常见的丢消息路径。
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（In-Sync Replicas）全部落盘才确认，配合 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，必须手动 commitSync/commitAsync
默认 enable.auto.commit=true 是最大陷阱：它按固定间隔（如 auto.commit.interval.ms=5000）提交 offset，不管业务逻辑是否执行完。HTTP handler 中调用 consumer.Commit() 前 panic，或处理耗时超过间隔，都会导致 offset 提前提交、消息丢失。
- 务必设
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 事务不是银弹
哪怕开了 TransactionalID，只要业务逻辑失败、服务崩溃、或消费者处理出错，消息依然可能“已提交但未生效”。真正的可靠投递靠的是「业务库写入 + 消息表插入」在同一个 *sql.Tx 中完成，再由独立补偿服务扫描未发送的消息表记录。
立即学习“go语言免费学习笔记（深入）”；
- 表结构至少含：
id（主键）、topic、key、value（JSON 或 Protobuf）、status（pending/sent/failed）、created_at - 插入消息记录必须与业务 INSERT 在同一事务内，且在
tx.Commit()之前完成 - 禁止用
go func() { ... }()异步写消息表——goroutine 不受事务控制，崩溃即丢失 - 补偿服务需具备幂等重发能力，并监听 Kafka 的
__transaction_state主题（仅当用事务时）或自建状态机
日志采集类场景优先选 sarama.AsyncProducer，别碰 kafka-go 事务
高吞吐日志打点（如每秒万级 event）不适合用 kafka-go 的事务模式：InitTransactions/BeginTransaction/CommitTransaction 的 RT 波动大，且每个事务有 2 轮 RPC 开销，极易成为瓶颈。sarama 的 AsyncProducer 更适合，但配置错误会导致静默丢消息。
- 必须设
Config.Producer.Return.Successes = true，否则Successeschannel 永远不吐结果，无法感知失败 - 禁用
SyncProducer：它阻塞调用线程，会拖垮 HTTP handler，且无超时控制 -
Successeschannel 要带缓冲（如make(chan *sarama.ProducerMessage, 100)），否则峰值时阻塞 producer 输入 - 消费
Successes和Errorschannel 必须用select+default或超时，防止 channel 堵塞导致整个 producer 卡死
最易被忽略的一点：所有 Kafka 客户端都依赖 DNS 解析和 TCP 连接复用，但 Go 默认的 net/http.DefaultTransport 与 confluent-kafka-go 的连接池互不感知。混用时可能出现连接泄漏、DNS 缓存过期不刷新、或 TLS 握手竞争。生产环境务必为 Kafka 客户端单独配置 Net.DialContext 和 tls.Config，不要复用 HTTP transport。
