zmq4是c版zeromq 4.x的cgo封装，需预先安装系统级libzmq；创建上下文后必须defer ctx.terminate()；req/rep须严格配对收发；pub/sub中sub须先connect再setsubscribe；send/recv默认阻塞，须手动设超时和健康检查。
直接上结论：zmq4 不是纯 Go 实现，而是对 C 版 ZeroMQ 4.x 的 CGO 封装，用它前必须先装好系统级 libzmq，否则编译失败或运行时 panic —— 这是 90% 新手卡住的第一步。
安装 zmq4 前必须确认 libzmq 已就绪
zmq4 本身不带 ZeroMQ 库，只提供 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：需手动下载预编译的
libzmq（如 vcpkg 安装），并设置CGO_CFLAGS和CGO_LDFLAGS指向头文件和 .lib 文件 - 验证是否可用：
pkg-config --modversion libzmq应输出类似4.3.4；go env CGO_ENABLED必须为1
创建 socket 时别漏掉 defer ctx.Terminate()
ZeroMQ 要求每个进程有且仅有一个上下文（zmq4.Context），它管理所有 socket 生命周期和底层线程池。漏掉终止会导致资源泄漏，尤其在频繁启停的服务中，可能触发 too many open files。
- 正确写法：
ctx, _ := zmq4.NewContext(); defer ctx.Terminate() - 错误写法：只
defer socket.Close()，但没关上下文 —— socket 关了，后台 I/O 线程还在跑 - 注意：
ctx.Terminate()是阻塞调用，会等所有 socket 彻底关闭后才返回，不要在热更新逻辑里误用
REQ/REP 模式必须严格配对收发，否则卡死
REQ socket 强制要求“发→收→发→收”循环，REP 则是“收→发→收→发”。任意一方跳步（比如 REQ 连续发两次），连接会进入不可恢复的错误状态，后续调用 Send 或 Recv 直接返回 zmq4.ErrEFSM（finite state machine error）。
- 典型翻车场景：客户端异常退出后未重连，服务端仍尝试
Send，下一次Recv就失败 - 调试技巧：加
log.Printf("before Send: %s", msg)和log.Printf("after Recv: %s", reply)，确认顺序 - 生产建议：用
socket.SetRcvtimeo(5000)和socket.SetSndtimeo(5000)防止无限阻塞
PUB/SUB 默认不投递历史消息，SUB 必须先 Connect 再 SetSubscribe
PUB 发送消息时，只会推给当前已建立连接且已设置订阅前缀的 SUB socket。如果 SUB 先 Recv 再 SetSubscribe，或 Connect 太晚，就会收不到任何数据 —— 这不是丢包，是 ZeroMQ 的设计行为。
- 正确顺序：
sub.Connect("tcp://...")→sub.SetSubscribe([]byte(""))（空字节表示接收所有）→sub.Recv(0) - 陷阱：
SetSubscribe必须在Connect之后、首次Recv之前调用；改订阅前缀需重新Connect或用SetUnsubscribe/SetSubscribe动态调整 - 冷启动问题：PUB 启动早于 SUB，SUB 可能错过第一批消息 —— 业务层需自行实现重放或快照同步
最易被忽略的一点：zmq4 的 Send 和 Recv 默认是阻塞的，且没有内置重试或断线重连逻辑。网络抖动、服务重启、防火墙策略变更都会让通信中断，而这些情况不会抛出明确错误，只会卡在 syscall 上 —— 所以超时设置和连接健康检查必须由你亲手补全。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
