不能。enable.idempotence=true仅在生产者端通过PID+序列号实现Broker侧去重，对消费者重复消费完全无效；防重复消费必须在消费者代码中基于业务唯一键（如order_id）结合Redis或DB做幂等校验。
enable.idempotence=true 能解决消费者重复消费吗？
不能。这个配置只作用于生产者端，对消费者完全无效。
Kafka 的 enable.idempotence=true 是 Broker 针对单个生产者实例做的服务端去重：它靠 PID + Sequence Number 校验消息是否重复写入，仅在生产者重试时起作用。消费者拉取到的消息，无论是否重复，Broker 都会原样返回——幂等性不延伸到消费链路。
常见误解是开了这个就“万事大吉”，结果上线后订单还是被创建了两次。真正要防重复消费，得在消费者代码里做文章。
Go 消费者怎么实现业务级幂等？
核心思路是：收到消息后，先查状态，再执行，最后落库标记。不是靠 Kafka 机制，而是靠你自己的判断逻辑。
立即学习“go语言免费学习笔记（深入）”；
- 提取业务唯一键，比如
order_id、payment_id或trace_id - 用这个键查 Redis 或数据库，确认该操作是否已处理过
- 若已存在，直接返回成功（不抛错、不重试）；若不存在，执行业务逻辑并写入幂等记录
- 注意：Redis 写入必须带
EX过期时间（如SET order_id:123 "done" EX 86400），否则宕机后状态丢失，下次又会重复 - MySQL 场景建议建唯一索引（如
UNIQUE KEY (order_id)），插入失败即说明已处理
别依赖本地内存缓存，Go 服务多实例部署时，各进程缓存不共享，会漏判。
go-zero 的 StableRunner 能自动防重复吗？
不能。StableRunner 只保证单 Partition 内消息顺序和稳定并发，并不内置幂等校验。
它的典型用法是把消息推给 goroutine 处理，但如果你的 processMessage() 函数没做去重，重复消息照样进业务逻辑。
正确做法是在 handler 里补上幂等检查：
func (h *KafkaHandler) Process(msg *sarama.ConsumerMessage) error {
orderID := extractOrderID(msg.Value)
if exists, _ := h.idempotentStore.Exists("order:" + orderID); exists {
return nil // 已处理，静默跳过
}
if err := h.createOrder(orderID); err != nil {
return err
}
h.idempotentStore.Set("order:"+orderID, "done", 24*time.Hour)
return nil
}
这里 idempotentStore 是你自己封装的 Redis 或 DB 客户端，不是框架自带的。
为什么 Kafka 自身不提供消费者幂等能力？
因为“是否重复”取决于业务语义，Kafka 无法定义。
同一条消息：{"order_id":"123","amount":100}，对支付系统是严格幂等（扣一次款），对日志系统可能根本不在乎重复；对风控系统，甚至需要多次分析同一笔交易。Broker 不知道你的业务规则，所以把判断权交还给消费者。
这也意味着：没有通用的“Kafka 消费幂等开关”，每个业务都要按自己关键字段设计去重逻辑。最容易被忽略的是——幂等存储本身必须可靠，如果 Redis 挂了又没降级方案，整个流程就失效了。
