Go集成Kafka常见问题根源在于broker与客户端参数未对齐：advertised.listeners配置错误导致连接失败；RequiredAcks未设为WaitForAll且replication.factor不足致消息丢失；kafka-go消费者因offset提交策略不当而卡死；生产者非线程安全却在init中全局初始化引发panic；broker端min.insync.replicas与acks不匹配造成超时。
Go 语言集成 Kafka 的生产者/消费者模型，不是“配好就能跑”的玩具项目——本地连不上 localhost:9092、发完消息收不到、消费卡死、重启后消息丢失，几乎全是配置或初始化逻辑踩坑导致的。关键不在语法，而在 Kafka broker 和 Go 客户端两端的参数对齐。
本地调试连不上 localhost:9092？先查 advertised.listeners
Kafka broker 默认只监听 localhost，但客户端（尤其是 Docker 容器或远程机器）会按 advertised.listeners 配置里的地址去连。如果你用 docker run 启动 Kafka，却在宿主机 Go 程序里写 "localhost:9092"，十有八九失败。
- 检查
config/server.properties中是否设置了advertised.listeners=PLAINTEXT://localhost:9092（开发环境可这样设） - 若用 Docker，必须映射端口且显式指定该配置，例如：
docker run -p 9092:9092 -e KAFKA_ADVERTISED_LISTENERS=PLAINTEXT://localhost:9092 ... - 不改
advertised.listeners而只改listeners没用，客户端根本拿不到正确连接地址
sarama.NewSyncProducer 成功返回 ≠ 消息已落盘
NewSyncProducer 名字带 “Sync”，容易误以为“发出去就稳了”。实际它只保证请求发到 broker 并收到响应，是否持久化完全取决于 RequiredAcks 和 broker 配置。
- 默认
config.Producer.RequiredAcks = sarama.NoResponse：发完即返，broker 甚至没写页缓存，宕机就丢 - 设为
sarama.WaitForAll才真正要求所有 ISR 副本写入；但若 topic 的replication.factor=1，它退化为只等 leader，仍不防单点故障 - 务必开启
config.Producer.Return.Successes = true，否则SendMessage成功后你连 partition 和 offset 都不知道
kafka-go 消费者卡住？大概率是 offset 提交策略错了
kafka-go 的 consumer.ReadMessage 是阻塞调用，但它卡住通常不是 Kafka 问题，而是应用层没管好 offset —— 提交太勤或太懒都会出事。
立即学习“go语言免费学习笔记（深入）”；
- 每条消息都立刻
CommitMessages：吞吐暴跌，RTT 成瓶颈；且提交后 crash，消息会被重复消费 - 完全不手动提交、依赖
AutoCommit: true：consumer 重启时从上次自动保存位置开始，可能跳过未处理完的消息 - 推荐做法：批量处理 10–100 条后调用
CommitMessages；同时给ReadMessage加context.WithTimeout，避免无限阻塞
别在 init() 里全局初始化生产者
sarama 生产者不是线程安全的，kafka-go 的 Writer 也不是。在 init() 函数里创建单例并到处传引用，高并发下会 panic。
- 应封装成结构体，内部持有一个 producer 实例 + 互斥锁，或用对象池（
sync.Pool）管理 - 尤其注意
sarama不自动关闭底层 TCP 连接：producer.Close()必须显式调用，否则 goroutine 泄露、连接堆积，broker 日志出现Connection reset - 用
defer producer.Close()只适用于短命命令行工具；服务长期运行需在 shutdown 信号中统一 close
最常被忽略的是 broker 端配置和客户端参数的耦合性——比如设了 acks=all，但 topic 的 min.insync.replicas=2 而实际只有 1 个副本在线，生产者就会一直超时。调不通时，先看 broker 日志，再比对两边配置，而不是反复改 Go 代码。
