来自维基百科：“发布/订阅（或发布/订阅）是一种消息传递范式，其中消息的发送者（发布者）没有被编程为将他们的消息发送给特定的接收者（订阅者）。相反，发布的消息被描述为类，而不知道可能有什么（如果有的话）订阅者”
我可以理解为什么不能对发送者进行编程以将其消息发送给特定的接收者。但是为什么发布的消息必须是不知道其订阅者的类呢？
似乎一旦消息系统本身就位，随着软件的发展，通常会发生变化的是发送的消息、发布者和接收者。将消息与订阅者分开似乎意味着订阅模型也可能发生变化。这是原因吗？另外，这在现实世界中会发生吗？
我意识到这可能是一个基本问题，但我正在努力理解这种范式，非常感谢您的回复。
我认为这条规则无论如何都不是绝对的，如果你能找到了解订阅者的消息有用的情况，我认为没有人会告诉你你错了（他们可能会告诉你有但是，更好的方法）。
但是请记住，消息知道其订阅者会直接影响可伸缩性和向后兼容性。
兼容性方面，当一个新进程想要订阅消息时会发生什么？谁负责让消息知道（这是否会默认为发布者）？以及这个新要求如何阻止您保留过去的消息以供将来使用，因为他们不会知道未来的订阅者。
可扩展性方面，当您的消息系统变得流行，并且每个人和他们的母亲开始为您的应用程序开发不同的订阅者（如 twitter）时会发生什么？您如何处理每条消息被发送一千次（每个订阅客户端一个）或发送一条更大的消息？这可能会阻止您使用其他技术，例如 SMS，或为可靠传输技术创建更大的延迟。
这可能是为了避免进一步的头痛。
这只是关注点分离、遵守接口和隔离。为什么你认为他们需要了解他们的订阅者？
一条消息被张贴到公告板上。有多个不同主题的公告板。可能没有读者。可能有读者（订阅者）每天都来查看版块中感兴趣的主题。可能有 10,000 名读者阅读它们。
只要消息是用读者应该知道的语言编写的，为什么发布者（发布者）或消息本身需要了解有关订阅者的任何其他信息？
我认为消息了解用于消息的接口/合同接收者，但仅此而已。
似乎这种模型还允许单向信息流……为了了解有关您的订阅者的某些信息，必须有双向信息流。