让我们从第二个nd 问题开始：抱歉，这是预期的行为
ZeroMQ 原型被定义为代表某种行为。如前所述，PUSH-archetype AccessPoint 将每条消息“通过”所有迄今为止设置的通信渠道，PULL-er AccessPoint 将任何已经到达的东西拉到“它的手中”，PUB- lisher AccessPoint 发布，SUB-scriber AccessPoint 订阅，以便仅接收与其主题过滤器匹配的消息，但不接收任何其他消息。
看起来很清楚，这样的 Archetype“规范”有助于构建 ZeroMQ 智能消息传递/信令基础架构，以便我们在 distributed-systems 架构中轻松使用。
为什么它没有发送一条消息？简单地说，它不能交付。
按照定义，刚刚实例化的 SUB 侧 AccessPoint 对象实际上是零机会知道哪些消息是正确的，因此它们应该是“已发送”以及哪些消息未发送。
如果没有这个初始知识，ZeroMQ 设计者的主要选择是要么原型策略一致，并让PUB-side AccessNode 将所有.send()-acquired 获取的消息分发给那些SUB-side AccessNode(s)，已经明确要求接收任何此类，直接通过zmq.SUBSCRIBE-mechanics或将PUB发送的所有内容发送到所有迄今为止联合国-决定SUB-s.
前者是来自 ZeroMQ 作者的一致且专业的设计步骤。
后者实际上意味着违反 ZeroMQ 自己的 RFC 规范。
后一种选择就像如果一个人刚搬到一个新公寓，那么你几乎不会期望从第二天早上开始，所有的报纸和杂志都会出现在他的新邮箱中，不是吗？但是，如果您订阅了《波士顿环球报》，那么第二天早上，新版本就会出现在门口，因为它将一直存在，直到您取消订阅或报纸破产或缺少纸卷而导致印刷厂无法交付在适当的时候和时尚或 Big Dig 隧道中的交通堵塞可能会在某一天给所有或只是本地交付造成麻烦。
这一切都是自然的，并且与原型政策兼容。
间奏曲：
技术纯粹主义者会在这里反对，早期的 API 版本（直到 v3.2+）实际上确实在技术上将所有消息有效负载从PUB 传输到所有SUB-s，因为它简化了PUB-side 工作负载信封，但增加了传输类数据流和SUB-side 资源/延迟主题过滤器处理。然而，所有这些都隐藏在用户代码中，就在抽象的 API 范围内。因此，除了需要适当地扩展资源之外，这对用户来说是透明的。最近的 API 版本恢复了主题过滤器处理器的角色，并让这现在发生在 PUB 端。尽管如此，在这两种情况下，ZeroMQ RFC 规范策略都是以这样的方式实现的，SUB-side 永远不会传递（通过.recv()-interface）与有效的显式@987654342 不匹配的单个消息@-side 订阅
在所有情况下，SUB-side 尚未明确设置任何 zmq.SUBSCRIBE-instructed 主题过滤器，它不能也不会提供任何东西（这是自然且完全一致的使用为 SUB-type AccessPoint 定义的 ZeroMQ RFC Archetype-policy。
第一个st问题的答案：最好的下一步：
至少，请始终阅读 ZeroMQ API 文档，其中所有细节都经过专业说明 - 这样至少，人们可以初步了解智能消息传递/信令框架的气息。
这无助于任何人开始一个新的领域并完全建立自己的复杂心理概念和对所有事物内部如何运作的深入理解，这显然不是任何 API 文档的野心，是吗？然而，一旦掌握了 ZeroMQ 内部架构，这将有助于任何人刷新或提醒所有可配置的细节，如源代码中详述的，在下一段中提到。
另外，对于任何确实对distributed-systems 或仅对zeromq 本身感兴趣的人，值得花时间和精力阅读 Pieter HINTJENS 的书“Code Connected, Volume 1”（可在pdf ) 以及他后来关于他在软件工程方面的丰富经验的任何其他书籍，因为他对现代计算的许多见解可能并且将会激发（并且很多）。