kafka在go中可靠性取决于配置匹配：sarama需显式设requiredacks=waitforall、return.successes=true及正确version；kafka-go更简洁但兼容性弱；网络配置、advertised.listeners和认证易致生产超时。
Kafka 在 Go 里不是“装个包就能用”，而是“配错一个参数就丢消息”——生产环境最常出问题的，是 sarama.NewConfig() 的默认值。
为什么 sarama.NewSyncProducer 明明返回成功却收不到消息？
因为默认配置下它根本不管 Broker 是否真正写入：
config.Producer.RequiredAcks 默认是 sarama.NoResponse，发完即返，Broker 崩了也报“成功”；
config.Producer.Return.Successes 默认是 false，你连 partition 和 offset 都拿不到，更没法做幂等或重试校验。
- 必须显式设为：
config.Producer.RequiredAcks = sarama.WaitForAll - 必须打开：
config.Producer.Return.Successes = true - 别忘了匹配 Kafka 版本：
config.Version = sarama.V3_6_0（对应 Kafka 3.6+，配错会静默失败或报UNKNOWN_TOPIC_OR_PARTITION）
同步发送 vs 异步发送：什么时候该用 sarama.AsyncProducer？
同步模式（sarama.NewSyncProducer）适合关键链路，比如支付确认、订单落库后发事件，它阻塞等待 ISR 全部写入，延迟高但语义强；异步模式（sarama.NewAsyncProducer）吞吐高，但错误要从 Errors() 和 Successes() channel 里手动收，且默认不保证顺序。
- 异步模式下，若需顺序，得固定
Key并开启config.Producer.Partitioner = &sarama.HashPartitioner{} - 异步模式必须自己处理
Errors()channel —— 不读就会阻塞整个 producer - 线上建议：非核心日志类消息用异步，业务主链路用同步 + 重试封装
kafka-go 和 sarama 怎么选？别只看文档热度
kafka-go（segmentio/kafka-go）API 更简洁，原生支持 context，幂等生产者开箱即用（EnableIdempotence: true），但对旧 Kafka 版本兼容性弱；sarama 功能全、社区久、文档多，但 API 繁琐，版本配置、重连、心跳都得手撸。
- 新项目、Kafka ≥ 2.8，优先试
kafka-go：它的WriteMessages天然支持批量 + 重试 + 幂等 - 老系统、Kafka ≤ 2.4 或要用 KRaft 模式，
sarama更稳，但务必用sarama.Vx_x_x显式指定版本 - 两者都不自动重连：网络抖动后，
sarama会卡死在SendMessage，kafka-go的Writer会 panic，都得自己包一层健康检查和重建逻辑
本地跑通了，一上生产就超时？查这三处
本地单机 Kafka 跑得飞起，生产集群却频繁 context deadline exceeded 或 io timeout，大概率不是代码问题，而是网络与配置没对齐。
- Broker 地址必须用内网 DNS 或 VIP，别写
localhost:9092或容器名——Go 客户端解析不了 - 检查
advertised.listeners：Kafka 配置里这个参数决定它告诉客户端“你该连谁”，配错会导致客户端连到不可达地址 - 云厂商 Kafka（如腾讯云 CKafka、阿里云 MSK）通常要求 SASL 认证，
security.protocol和sasl.mechanism必须配对，且用户名密码不能硬编码在代码里
真正难的从来不是“怎么发”，而是“怎么确定它真的发到了”。Kafka 的可靠性，90% 取决于配置是否匹配你的 Kafka 版本和部署拓扑，剩下 10% 才轮到 Go 代码本身。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
