Kafka + Go 实现真正解耦的关键在于消费者组设计、消息重试策略和业务幂等落地；仅引入库而不落实这三点，会导致消息积压或重复消费。
直接说结论：Kafka + Go 不是“加个库就能解耦”，关键在消费者组设计、消息重试策略和业务幂等落地。没做这三件事，解耦只是假象，迟早变成消息积压或重复消费。
为什么 sarama 的 ConsumerGroup 必须用，不能只用 Consumer
单个 Consumer 实例无法自动分配分区，也不能在扩容时重新平衡负载——这意味着你手动启多个进程，得自己管 offset、自己防重复、自己处理崩溃后的再均衡。而 ConsumerGroup 由 Kafka broker 统一协调，只要服务实例加入同一 group ID，分区自动分配，宕机后自动转移，这才是生产级解耦的基础。
- group ID 必须全局唯一且稳定，比如
"order-processor-v2"，改名会导致 offset 丢失 - 每个 consumer 实例必须调用
Consume并实现ConsumerGroupHandler接口，否则不参与 rebalance - 不要在 handler 里做耗时同步操作（如直连数据库写入），否则会拖慢整个 group 的心跳和 offset 提交
Producer 发送失败时，Return.Errors 和 Return.Successes 怎么配
默认两者都关，意味着发出去就不管结果。这对日志类消息可能够用，但对订单、支付等核心事件，等于把可靠性交给运气。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 务必开启
config.Producer.Return.Errors = true，否则SendMessage永远不报错，网络抖动或 topic 不存在时消息静默丢弃 -
config.Producer.Return.Successes = true可选，但开启后能拿到partition和offset，方便后续排查或做顺序保证 - 注意：开启
Return.Errors后，必须用select监听Errors()channel，否则 goroutine 泄漏
消费者如何避免重复消费导致业务错乱
Kafka 只保证 at-least-once，不是 exactly-once。靠 broker 设置解决不了问题，必须在业务层落地幂等。
立即学习“go语言免费学习笔记（深入）”；
- 不要依赖消息体里的 UUID 做去重——重试时 producer 可能生成新 ID
- 推荐方案：用业务主键（如
order_id）+ 事件类型（如"order_created"）拼成唯一 key，写入 Redis 或数据库前先SETNX或INSERT ... ON CONFLICT DO NOTHING - offset 提交时机很重要：必须在业务逻辑成功执行后才提交，且建议用
CommitMessages手动提交，别依赖自动提交（容易在处理中途 crash 导致重复）
最容易被忽略的点：Kafka 的 auto.offset.reset 配置。开发环境常设为 earliest，上线后若误留，会导致历史全量消息重放，瞬间打垮下游服务。上线前务必核对 consumer config 中该值是否为 latest 或按需设为 none 并兜底报错。这不是配置项细节，是解耦能否稳住的分水岭。
