ZeroMQ不是传统消息队列，而是无Broker的通信库；其REQ/REP、PUB/SUB、PUSH/PULL三种模式分别适用于同步调用、广播分发和任务流水线，选错模式会导致阻塞、丢消息或无法扩展。
ZeroMQ 不是传统意义上的消息队列中间件（比如 RabbitMQ 或 Kafka），它不保存消息、不提供持久化、也没有中心 broker。你在 C++ 里“用 ZeroMQ 做消息队列通信”，实际是用它提供的通信模式（如 REQ/REP、PUB/SUB、PUSH/PULL）模拟队列行为——关键看你要解决的是哪类问题：同步调用？广播分发？还是任务流水线？选错模式会导致阻塞、丢消息或无法扩展。
初始化上下文和 socket 必须配对，且不能跨线程复用 socket
ZeroMQ 的 zmq::context_t 是线程安全的，但 zmq::socket_t 不是。一个 socket 只能在创建它的线程中使用。
- 上下文一般进程内只建一个：
zmq::context_t ctx(1)，参数是 I/O 线程数，1 足够多数场景；设太高反而增加调度开销 - 每个 socket 必须明确指定类型：
ZMQ_REQ、ZMQ_PUB、ZMQ_PUSH等，类型一旦确定不可更改 - 不要在多个线程里共享同一个
socket实例——即使加锁也不行；需每个线程新建 socket 并复用同一 context - 忘记调用
socket.close()或 context 析构前未关闭 socket，可能导致端口残留或资源泄漏
REQ/REP 模式不是“请求-响应队列”，而是严格同步握手
很多人误以为 REQ/REP 能像 HTTP 那样并发发多个请求再异步收响应，但它强制“一问一答”顺序：客户端发完必须 recv，服务端 recv 后必须 send，中间不能跳步。
- 客户端连续 send 两次不 recv → 第二次 send 会阻塞或报
EFSM错误（state machine violation） - 服务端 recv 后没 send 就再次 recv → 同样触发
EFSM，socket 进入不可恢复错误状态 - 想支持多请求并行？得换
DEALER/ROUTER，或用多个 REQ socket + 线程池，而不是硬撑单个 REQ - 默认阻塞，加
zmq::recv_flags::dontwait可非阻塞，但要自己处理EAGAIN
SUB 端收不到历史消息，且空订阅字符串有陷阱
ZMQ_SUB socket 默认不接收任何消息，必须显式调用 setsockopt(ZMQ_SUBSCRIBE, ...) 才生效。空字符串 "" 表示订阅所有，但容易被忽略其二进制含义。
立即学习“C++免费学习笔记（深入）”；
-
socket.setsockopt(ZMQ_SUBSCRIBE, "");看似简单，实际传的是 C 字符串首地址 + 长度 0 —— 这是合法的“全订阅”，但若误写成socket.setsockopt(ZMQ_SUBSCRIBE, "a\0b")，只会订阅"a"（遇到第一个 \0 就停） - SUB 连接建立前发布的消息一定丢失，ZeroMQ 不缓存；需要消息回溯能力？得自己加外部存储或换
XPUB/XSUB+ 代理层 - 多个 SUB 连接同一 PUB 时，PUB 发一次，所有 SUB 都收到副本——这不是“队列消费”，而是广播；真要负载均衡，请用
PUSH/PULL - 网络不稳定时，SUB 可能静默断连又重连，期间消息丢失无通知；建议加心跳或序列号校验
PUSH/PULL 才最接近“任务队列”的直觉，但要注意公平分发边界
PUSH 发送任务，PULL 接收，ZeroMQ 内部用“公平队列”（fair-queuing）算法分发，适合 worker pool 场景。
- PUSH 到多个 PULL 时，消息按连接顺序轮询分发，但前提是所有 PULL 已连接且就绪；如果某个 PULL 启动晚或卡住，它会持续饥饿
- PULL 端处理慢会导致 PUSH 端缓存积压，默认高水位（
ZMQ_SNDHWM）是 1000 条，超限后 PUSH 会阻塞或丢弃（取决于ZMQ_BLOCKY和ZMQ_IMMEDIATE设置） - 想让慢 worker 少拿任务？ZeroMQ 本身不支持优先级或权重；得在应用层加反馈机制（如 PULL 处理完发 ACK，PUSH 根据 ACK 速率动态调整发送节奏）
- IPC（
ipc:///tmp/zmq）比 TCP 更低延迟，适合本机多进程任务分发；但 Windows 不支持 ipc 协议，得 fallback 到tcp://127.0.0.1
真正难的不是写通第一段 send/recv，而是理解 ZeroMQ 每种 socket 类型背后的状态机约束——它把网络复杂性封装掉了，却把协议逻辑推给了你。bind/connect 方向、消息边界处理、多部分消息的 ZMQ_SNDMORE 标志、以及错误码 EAGAIN 和 EFSM 的具体含义，这些细节一旦出错，现象往往模糊（比如“有时卡住”“偶尔丢消息”），调试成本远高于写代码本身。
