go项目连不上消息队列主因是环境未就绪或配置缺失：kafka需先启动zookeeper/kraft、正确配置listeners/advertised.listeners、显式设置sarama.version并手动创建topic；rabbitmq需全局复用连接、配置心跳、channel按需新建；nsq/pulsar等同理，关键参数漏配将导致静默失败或丢消息。
Go 项目连不上消息队列，90%不是代码写错了，而是环境没对齐、配置漏了关键项，或者复用方式反模式。直接上手就 go get 然后调 NewSyncProducer 或 amqp.Dial，大概率卡住、静默失败、丢消息，但日志里看不出原因。
Kafka 连接卡在 NewSyncProducer 或报 UNKNOWN_TOPIC_OR_PARTITION
这不是 Go 代码问题，是 Kafka 服务根本没跑起来，或客户端版本和 Broker 不匹配。
- 先确认 ZooKeeper（或 KRaft）已启动：执行
bin/zookeeper-server-start.sh config/zookeeper.properties后，日志末尾要出现binding to port；KRaft 模式则需确保kafka-server-start.sh前已运行kafka-storage.sh format - 再检查
server.properties中的listeners和advertised.listeners是否都设为PLAINTEXT://localhost:9092（本地开发），否则 Sarama 会连到错地址 -
config.Version必须显式设成你实际安装的 Kafka 小版本，比如sarama.V3_6_0；填sarama.V2_8_0或留默认，可能触发UNSUPPORTED_VERSION且不报错 - 别跳过 topic 创建：用
bin/kafka-topics.sh --create --bootstrap-server localhost:9092 --topic test --partitions 1 --replication-factor 1手动建一次，验证 Broker 可写
RabbitMQ 连接反复 Dial 导致端口耗尽或 panic: send on closed channel
每次发消息都 amqp.Dial() 是线上事故高发点，连接数暴涨、LB 静默断连、Channel 复用错乱全由此来。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
-
*amqp.Connection必须全局单例，在main()初始化一次，封装进internal/mq/rabbitmq.go或 DI 容器，不要藏在 handler 里 - 必须配心跳：
amqp.Config{Heartbeat: 10 * time.Second}，否则 K8s Service 或云厂商 LB 在空闲 30 秒后掐断连接，后续操作直接 panic -
conn.Channel()每次使用前新建，用完立刻ch.Close()；Channel 不是线程安全的，跨 goroutine 共享必崩 - 消费者
ch.Consume()时autoAck必须为false，否则进程崩溃消息就永久丢失；ACK/NACK 要在同一个ch上调用，不能把msg传出去再 Ack
NSQ Producer 每次请求新建导致 too many open files
把 nsq.NewProducer("127.0.0.1:4150", cfg) 写在 HTTP handler 里，每秒几十个请求就会打满文件描述符，nsqd 开始拒绝新连接。
-
nsq.Producer实例必须全局复用，作为 service struct 字段或包级变量；初始化后必须显式调p.Connect()，否则Publish会静默失败 - 必须起 goroutine 监听
p.Err()，捕获io: read timeout等错误并做降级（比如切本地队列或告警），不处理就会卡死 - Consumer 连
nsqlookupd时，地址必须是tcp://127.0.0.1:4160，不是 HTTP 的4161；如果nsqd启用了--broadcast-address，Consumer 拿到的就是该地址，本地开发不设就别加--lookupd-tcp-address - Channel 名不是可选——同一 Topic 下不同 Channel 彼此隔离，改名后旧 Channel 积压的消息不会自动迁入，得手动清空
Pulsar serviceUrl 协议头写错导致 NewClient 一直 context deadline exceeded
Pulsar 客户端连不上，八成是 URL 协议头或 TLS 配置不对，而不是网络不通。错误日志只显示超时，不提 TLS，非常误导。
- 明文通信用
pulsar://localhost:6650，TLS 通信必须用pulsar+ssl://localhost:6651，且端口和服务配置必须严格对应 - 启用了 TLS 却用
pulsar://，客户端会在 handshake 阶段卡死，日志只有context deadline exceeded，查半天发现是协议头错了 - TLS 模式下
TrustCertsFilePath必须指向 PEM 格式 CA 证书（不是.crt或.pfx），路径要是绝对路径，或相对于二进制文件的相对路径 - Consumer 收不到消息，先看
ReceiverQueueSize是否设得过大（默认 1000），导致消息被预取走却没及时处理；SubscriptionType选错（比如该用Shared却用了Exclusive）也会让消息“消失”
所有中间件客户端最易忽略的点：配置不是“能连上就行”，而是每个字段都在参与可靠性决策。RequiredAcks、autoAck、durable、ReceiverQueueSize……这些看着像可选项，实则是消息是否落地、是否重试、是否乱序的开关。漏掉一个，测试时正常，压测或上线后某次网络抖动就出事。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
