zeromq 不适合作为微服务通用消息总线，但适合作为同机或局域网内低延迟内部传输层；zmq4 依赖系统 libzmq，需正确安装与配置；req/rep 必须严格遵循收发顺序并设超时；pub/sub 要求 sub 先 connect 再 setsubscribe；无内置重连与消息持久化，需业务层兜底。
直接说结论：ZeroMQ 不适合当微服务的“通用消息总线”，但作为同机或同局域网内服务间的极速内部传输层，它比 HTTP/gRPC 更轻、更低延迟——前提是绕开它不擅长的场景（如跨广域网、强一致性、消息持久化）。
zmq4 必须和系统级 libzmq 绑定安装，否则编译就失败
zmq4 是 CGO 封装，不是纯 Go 库。跳过这步，go build 会报 undefined reference to zmq_ctx_new 或 pkg-config: exec: "pkg-config": executable file not found。
- Linux（Debian/Ubuntu）：
sudo apt install libzmq3-dev pkg-config - macOS：
brew install zeromq pkg-config - Windows：用 vcpkg 安装后，必须设环境变量：
CGO_CFLAGS=-I<vcpkg-install-path>/include</vcpkg-install-path>，CGO_LDFLAGS=-L<vcpkg-install-path>/lib -lzmq</vcpkg-install-path>；部署时还得把libzmq-mt-4_3_4.dll打包进去 - 验证是否就绪：
pkg-config --modversion libzmq应输出类似4.3.4；go env CGO_ENABLED必须是1
REQ/REP 模式卡死？90% 是收发顺序错或没设超时
REQ socket 强制要求“Send → Recv → Send → Recv”，REP 则是“Recv → Send → Recv → Send”。任意一方跳步（比如客户端连续两次 Send），后续调用直接返回 zmq4.ErrEFSM，连接不可恢复。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 服务端必须在
Recv()后紧跟着Send()，不能漏掉响应 - 客户端必须在
Send()后立刻Recv()，不能只发不收 - 默认阻塞，生产环境务必加超时：
socket.SetRcvtimeo(5000)和socket.SetSndtimeo(5000)，避免单点故障拖垮整个调用链 - 别只
defer socket.Close()，必须defer ctx.Terminate()，否则 I/O 线程残留，too many open files早晚爆
PUB/SUB 模式收不到消息？SUB 必须先 Connect 再 SetSubscribe
ZeroMQ 的 PUB/SUB 是“即刻投递”模型：PUB 只向当前已连接且已设置订阅前缀的 SUB 推送。SUB 如果先 Recv() 再 SetSubscribe()，或 Connect() 晚于 PUB 启动，就会一条消息都收不到——这不是 bug，是设计如此。
- 正确顺序：创建 SUB socket →
Connect()→SetSubscribe("prefix")→Recv() - 空订阅（接收所有）写法是
SetSubscribe("")，不是SetSubscribe(nil)（后者无效） - 没有内置重连机制，断连后需手动重建 socket；建议用 goroutine + backoff 重试，而不是依赖
ZMQ_RECONNECT_IVL（它只对底层 TCP 有效，不保证语义重连） - 别指望“离线消息补偿”：PUB/SUB 天然不存历史，要补发得靠上游业务逻辑兜底（比如结合 Redis 记录 last_seq）
真正难的不是写通 REQ/REP 或 PUB/SUB，而是把 ZeroMQ 嵌进微服务生命周期里：上下文何时初始化、socket 连接池怎么管、错误后如何优雅降级、监控指标怎么暴露——这些没法靠 zmq4.NewSocket() 一行代码解决。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
