观察者模式与发布订阅模式本质不同：前者是对象间紧耦合的同步通知，后者通过事件总线实现松耦合异步通信；适用场景分别为模块内实时响应和分布式系统跨服务通信。
观察者模式和发布订阅模式听起来很像，实际使用中也常被混用，但它们在结构和应用场景上有明显区别。理解这些差异，能帮助我们在实际开发中做出更合适的设计选择。
观察者模式：对象间的紧耦合通知
观察者模式定义了对象之间的一对多依赖关系，当一个对象的状态发生变化时，所有依赖它的对象都会收到通知并自动更新。
在这种模式下，主题（Subject）直接维护一个观察者（Observer）列表，一旦状态改变，就遍历列表调用每个观察者的更新方法。
特点：
- 主题和观察者之间是双向通信，观察者需要注册到主题上
- 两者之间存在直接依赖，主题知道观察者是谁
- 通常是同步调用，通知发生时立即执行回调
实战案例：用户界面更新
比如一个天气应用，当前温度变化时，多个UI组件（如温度显示、趋势图、提醒模块）都需要更新。使用观察者模式，TemperatureSubject 维护一组 Observer，一旦温度数据更新，调用 notifyObservers()，所有注册的 UI 模块 receiveUpdate() 被触发。发布订阅模式：通过事件总线解耦
发布订阅模式引入了一个中间角色——事件总线（或消息代理），发布者不直接通知订阅者，而是将消息发送给事件通道，由通道负责分发给匹配的订阅者。
这种设计实现了发布者与订阅者之间的完全解耦，双方不需要知道对方的存在。
特点：
- 发布者和订阅者互不知情，通过事件通道通信
- 支持异步处理，消息可以排队、缓存、延迟消费
- 可基于主题或事件类型进行过滤和路由
实战案例：系统事件通知
在一个电商系统中，订单创建后需要触发库存扣减、积分增加、短信通知等多个操作。使用发布订阅模式，OrderService 发布一个 order.created 事件到消息队列，InventoryService、PointService、SMSService 各自订阅该事件，独立处理，彼此不影响。核心区别总结
虽然两种模式都实现了“通知”机制，但本质不同：
- 耦合度：观察者模式是对象间直接绑定，发布订阅通过中间件解耦
- 通信方式：观察者通常是同步推送到观察者，发布订阅常为异步消息传递
- 扩展性：发布订阅更适合分布式系统，支持跨服务通信
- 控制权：主题控制通知时机，而事件总线决定消息如何路由和消费
如何选择？
在同一个应用模块内，对象状态变更需要实时响应，比如 MVC 中的模型与视图同步，适合用观察者模式。
在大型系统或微服务架构中，模块或服务之间需要松耦合通信，推荐使用发布订阅模式，借助 Kafka、RabbitMQ 或 EventBus 实现。
基本上就这些。关键不是叫什么名字，而是看是否需要解耦、是否跨进程、是否要求异步。根据实际场景选型，才能真正发挥设计模式的价值。
