# 概述
观察者模式（Observer Pattern）是一种**行为设计模式**。

它的核心思想是定义一种**一对多的依赖关系**。什么意思呢？就是让多个“观察者”对象同时监听某一个“主题”对象。
当这个主题对象的状态发生变化时，它会**自动通知**所有依赖于它的观察者对象，让它们能够自动更新自己。
![Gemini_Generated_Image_fhevojfhevojfhev.png](https://developer.qcloudimg.com/http-save/yehe-1367556/423d4f12a633a862afa1a8bfa066b1df.png)
# 面对的问题
1. **紧耦合与代码僵化**：主题对象（比如“商品库存”）**直接持有并调用**所有依赖它的对象（UI、邮件服务、仓库系统）。这导致主题类变得臃肿，且与具体观察者类紧密绑定。一旦要新增或删除一个观察者（比如增加一个“向运营仪表盘发送通知”的功能），就必须**修改主题类的源代码**，这违反了开闭原则。

2. **动态订阅关系难以管理**：观察者的需求可能是动态的。比如，用户可以选择是否接收降价通知。在程序运行时，如何优雅地让一个对象开始监听或停止监听另一个对象的状态？用硬编码的列表很难实现。

3. **意外的更新链**：如果观察者在自己更新的过程中，又间接导致了主题状态的二次变化，可能会触发不可预料的连锁更新，甚至循环通知，让调试变得异常困难。

我们可能会想：**“难道不能用简单的事件回调或者监听器列表吗？”** 

可以，但观察者模式提供了一套更标准、更结构化的契约（接口），明确了“主题”和“观察者”各自的职责，使得这种订阅关系更容易被理解、实现和维护。
# 解决方案
观察者模式的**解决方案**非常直观。它引入了两个核心角色：
![Gemini_Generated_Image_pktl43pktl43pktl.png](https://developer.qcloudimg.com/http-save/yehe-1367556/47714d4a914664b779cbfc61f9c2e2e7.png)
- **主题 (Subject / Publisher)**：也就是被观察的对象。它需要维护一个**观察者列表**，并提供用于**添加（订阅）** 和**移除（取消订阅）** 观察者的方法。最关键的是，当自身状态改变时，它会调用一个**通知方法**，遍历这个列表，告诉每个观察者：“我变了！”

- **观察者 (Observer / Subscriber)**：也就是监听变化的对象。它实现一个统一的**更新接口**（通常就是一个 `Update()` 方法）。当收到主题的通知时，就执行自己的更新逻辑。

这样一来，主题完全不知道也不关心具体的观察者是谁、它们具体要做什么。它只负责在变化发生时，向所有注册的观察者广播一个消息。而观察者则负责决定自己对这条消息作何反应。
**依赖倒置了**——是观察者依赖于主题的抽象接口，而不是主题依赖于具体的观察者。
# 应用场景
这个模式在哪些**应用场景**下特别有用呢？几乎任何需要“事件驱动”或“发布-订阅”机制的地方：
- **GUI事件处理**：这是最经典的例子。按钮被点击（主题）、菜单被选择（主题），会通知多个事件监听器（观察者）去执行相应操作。
- **分布式系统的事件总线**：微服务中，一个服务完成某项任务（如订单支付成功），发布一个事件，多个其他服务（库存服务、积分服务、消息推送服务）订阅并处理该事件。
- **数据监控与报警**：监控系统（主题）收集指标数据，当某个指标超过阈值时，通知一系列的报警器（观察者），如发邮件、发短信、记录日志。
- **模型-视图-控制器 (MVC)**：模型（主题）发生变化时，自动通知一个或多个视图（观察者）更新界面。

它的精髓在于，**将变动的发起者与响应者分离**，让系统能够以低耦合的方式应对变化。
# 代码示例
Go没有类和继承，但我们用接口和结构体组合可以很优雅地实现。
梳理一下实现步骤：
![Gemini_Generated_Image_jqvfs6jqvfs6jqvf.png](https://developer.qcloudimg.com/http-save/yehe-1367556/7c3cbf2fb645fa78f2beb6fa6b8bc6f8.png)
1. **定义观察者接口**：约定一个 `Update` 方法。这是所有观察者都必须遵守的契约。
```
type Observer interface {
    Update(string) // 参数可以传递上下文信息，比如商品名称
    GetID() string // 可选，用于标识观察者
}
```
2. **定义主题接口及基础实现**：主题需要管理观察者列表。

```
type Subject interface {
    Register(Observer)
    Deregister(Observer)
    NotifyAll()
}

// 一个基础实现，可以被具体主题嵌入
type BaseSubject struct {
    observers []Observer
}
func (s *BaseSubject) Register(o Observer) {
    s.observers = append(s.observers, o)
}
func (s *BaseSubject) Deregister(o Observer) {
    // 实现从切片中移除指定观察者的逻辑
    for i, obs := range s.observers {
        if obs.GetID() == o.GetID() {
            s.observers = append(s.observers[:i], s.observers[i+1:]...)
            break
        }
    }
}
func (s *BaseSubject) NotifyAll() {
    for _, observer := range s.observers {
        observer.Update("某个事件发生了") // 具体消息由具体主题决定
    }
}
```
3. **创建具体主题**：拥有自己的状态，并在状态改变时调用 `NotifyAll`。

```
type Inventory struct {
    BaseSubject // 嵌入基础主题，获得观察者管理能力
    itemName string
    inStock  bool
}
func (i *Inventory) SetStockStatus(inStock bool) {
    if i.inStock != inStock { // 状态确实改变了才通知
        i.inStock = inStock
        fmt.Printf("商品 %s 库存状态变为: %v\n", i.itemName, inStock)
        i.NotifyAll() // 关键一步：通知所有观察者
    }
}
// 可以重写NotifyAll，传递更具体的消息
func (i *Inventory) NotifyAll() {
    for _, observer := range i.observers {
        observer.Update(i.itemName)
    }
}
```

4. **创建具体观察者**：实现 `Update` 方法，定义收到通知后的行为。

```
type EmailNotificationService struct {
    id string
}
func (e *EmailNotificationService) Update(itemName string) {
    fmt.Printf("[邮件服务 %s]: 商品 %s 库存状态有更新，已发送邮件通知。\n", e.id, itemName)
}
func (e *EmailNotificationService) GetID() string {
    return e.id
}
```

5. **客户端组装**：将观察者注册到主题上。
```
func main() {
    iphone := &Inventory{itemName: "iPhone 15"}
    
    emailService := &EmailNotificationService{id: "mailer-1"}
    smsService := &SMSNotificationService{id: "sms-1"}
    
    iphone.Register(emailService)
    iphone.Register(smsService)
    
    // 当库存状态变化时，所有观察者自动被通知
    iphone.SetStockStatus(true)
}
```
# 优缺点
## **优点：**
- **符合开闭原则**：这是最大的优点。我们可以引入新的观察者类（比如新增一个微信机器人通知），而**无需修改主题的代码**。系统扩展性极佳。
- **实现运行时关系**：观察者与主题之间的关联可以在运行时动态建立或解除，非常灵活。
- **支持广播通信**：主题一次状态改变，可以通知无数个观察者，适合一对多的消息分发场景。
## **缺点与注意事项：**
- **通知顺序不可控**：观察者被通知的顺序可能取决于它们注册的顺序，但不应依赖于此。如果观察者之间有依赖关系，需要小心设计。
- **可能引起循环依赖**：如果观察者在`Update`方法中又修改了主题状态，可能导致无限循环的通知。我们需要确保更新逻辑是幂等的，或者避免在通知链中触发反向更新。
- **轻微的性能开销**：维护观察者列表和遍历通知会引入开销。如果观察者数量巨大，或通知非常频繁，需要考虑性能优化（如异步通知、批量通知）。
# 总结
当我们下次在设计一个模块，发现它的状态变化会影响到系统中多个分散的部分时，不妨停下来想一想：**“这里是不是可以用观察者模式？”** 

引入它，最初可能会多写一些接口和结构体，但它带来的**长期收益**是巨大的——它让我们的核心业务逻辑保持稳定和纯粹，将变化的可能性隔离到各个独立的观察者中。这极大地提升了代码的可维护性和可测试性。

它的核心思想是定义一种一对多的依赖关系。什么意思呢？就是让多个“观察者”对象同时监听某一个“主题”对象。当这个主题对象的状态发生变化时，它会自动通知所有依赖于它的观察者对象，让它们能够自动更新自己。

观察者设计模式-使用go语言实现

十倍工程师

编程语言

架构设计

观察者模式是一种行为设计模式，实现一对多依赖关系，当主题对象状态变化时自动通知所有观察者。适用于GUI事件处理、分布式系统、数据监控等场景，解耦主题与观察者，支持动态订阅关系，提升系统扩展性。

事件总线

数据监控

短信

2026新春采购季

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

观察者设计模式-使用go语言实现-腾讯云开发者社区-腾讯云

观察者设计模式-使用go语言实现

观察者设计模式-使用go语言实现

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐