Python nanomsg 的现代替代

nng 是 nanomsg 唯一推荐的生产级替代品，完全重写、api 更一致、默认启用重试与心跳；pynng 是唯一活跃 python 绑定，支持 asyncio 与同步接口；req/rep 迁移需严格遵循 send→recv 顺序并显式设超时。

nanomsg 已停更，NNG 是当前唯一推荐的生产级替代

nanomsg 项目自 2017 年起进入维护模式，官方明确不再接受新特性或安全更新；所有新项目应直接选用 nng（Nanomsg Next Generation），它不是简单升级，而是完全重写的现代通信库，API 更一致、线程模型更健壮、默认启用连接重试和心跳机制。

• 旧 nanomsg 的 nn_bind()/nn_connect() 在 NNG 中统一为 listen()/dial()，语义更清晰，且 dialer 可单独配置重连参数（如 reconnect_time_min）
• NNG 默认禁用 Nagle 算法，TCP 场景下延迟更低；nanomsg 需手动设 NN_TCPNODELAY 才能等效
• nanomsg 的 inproc:// 在 NNG 中行为更严格：必须先 listen() 后 dial()，否则报 nng.EINVAL —— 这是常见启动顺序错误根源

pynng 而非 nnpy：Python 用户该选哪个绑定

nnpy 项目已于 2021 年归档，不再兼容 Python 3.11+，且不支持 NNG 的异步 I/O 和 TLS；pynng 是目前唯一活跃、完整覆盖 NNG 协议族的 Python 绑定，支持 asyncio、trio，也提供同步接口。

• 安装只需 pip install pynng，无需编译 nanomsg/C 依赖（它自带静态链接的 NNG）
• nnpy 的 Socket(nnpy.AF_SP, nnpy.PUB) 写法在 pynng 中变为 Pub0() —— 协议类名即语义，不用记数字常量
• 若你用 asyncio，直接调 asend()/arecv()；同步场景下 send()/recv() 会自动阻塞，但注意：未设 recv_timeout 时可能永久挂起

REQ/REP 模式迁移最容易出错的三个地方

NNG 的 Req0/Rep0 行为比 nanomsg 更严格，尤其在超时和状态机管理上，很多“看似能跑通”的 nanomsg 代码迁过来会静默失败。

• nanomsg 允许连续多次 send()（发多个请求），NNG 的 Req0 必须严格 send() → recv() → send()，否则抛 nng.ESTATE
• Rep0 端必须先 recv() 再 send()，不能反着来；而 nanomsg 对此容忍度高，容易掩盖逻辑 bug
• 超时必须显式设置：recv_timeout=5000（单位毫秒），否则 recv() 阻塞无上限 —— 这是服务端卡死最常见原因

跨语言互通时，协议层兼容性比 API 更关键

NNG 和 nanomsg 的 wire protocol 不兼容，但 NNG 向下兼容 nanomsg 的 *socket types*（如 PUB/SUB），只要两端都用标准模式（非 raw）、不启用加密或自定义头，就能直连。

立即学习“Python免费学习笔记（深入）”；

• Go 用 mangos（nanomsg 生态）和 Python 用 pynng 的 Pub0/Sub0 可互通；但若 Go 端用了 mangos/v3（NNG 兼容版），Python 端就必须用 pynng，不能混用 nnpy
• 消息体必须是裸字节流；json 或 Protobuf 需自行序列化，NNG 不做任何编码转换 —— 别指望 send({"a":1}) 能自动转成字节
• TCP 地址写法要一致：tcp://127.0.0.1:5555 可以，tcp://localhost:5555 在某些系统 DNS 解析慢会导致连接超时，建议统一用 IP

真正麻烦的从来不是换库，而是旧代码里那些没显式处理超时、没检查返回值、靠运气跑通的 socket 交互逻辑。NNG 把这些“运气”全拿掉了，换来的不是额外工作量，是上线后少查三次凌晨三点的连接中断告警。