diff --git a/mediator-pattern/README.md b/mediator-pattern/README.md
new file mode 100644
index 0000000..ee91ec1
--- /dev/null
+++ b/mediator-pattern/README.md
@@ -0,0 +1,49 @@
+# 中介者模式
+
+## 定义
+
+> wiki: 中介者模式（Mediator Pattern）是用来降低多个对象和类之间的通信复杂性。这种模式提供了一个中介类，该类通常处理不同类之间的通信，并支持松耦合，使代码易于维护。中介者模式属于行为型模式。
+
+这个名字十分贴切了，跟现实中的中介很像...，比如一个租房的黑中介，所有租客只需要直接与中介通信即可，所有房主也是直接与中介通信即可，省去了自己找租客的麻烦，
+
+但是通过中介，总是要有一些代价的，在现实生活中是高昂的中介费...在代码中就是需要维护中介对象...
+
+具体的结构可以想象为由客户端与客户端直连的网状结构，变为了由一个服务器进行转发的星型结构。
+
+## 类图
+
+![](https://upload-images.jianshu.io/upload_images/2412598-4db4679a77baa25a.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1000/format/webp)
+(图源网络)
+
+从类图中可以看出，两个具体结构体并没有直接进行通信，而是通过一个具体中介者来通信的
+
+## 角色
+
+  - 抽象中介者
+  
+  - 具体中介者
+  
+  - 抽象客户端
+  
+  - 具体客户端
+
+## 举个栗子
+
+我觉得简单的例子并不能说明中介者的好处，因为对于只有一个两个的客户，使用中介者本身就不是好的设计，中介者模式是用在大量对象的松散耦合上的，类比路由器...
+
+所以这里直接举一个实际应用的例子: `MVC`!
+
+ `MVC` 结构是一个典型的中介者模式，`C`(控制器) 就是 `M`(模型) 与 `V`(视图) 之间的中介者
+ 
+ > 多说一句题外话，现在的 MVC 模式并不够抽象，控制器的功能应该仅仅包含处理URL，而真正的逻辑应该放在 Services(服务) 中去处理,现在的很多项目都没有 Services,其中一个原因就是项目体量太小，很多人为了简便，便将业务逻辑直接写入了控制器中。
+ 
+而具体的实现代码: 我在之前写过一篇 [使用Go写一个简易的MVC的Web框架](https://juejin.im/post/5b7240aaf265da282809f11e) ，里面完成了一个 `web` 服务器，在控制器中沟通数据库并打印网页，就完成了一个完整的 `MVC` 结构。
+
+当然这个框架是我第一版写的了... 现在的代码基本上全部重写了...
+
+## 小结
+
+ - 优点: 降低了类之间的耦合，从而降低了项目的复杂度
+ 
+ - 缺点: 随着项目的变大，中介者会变得越来越大，越来越复杂，对中介者的解耦也变得越来越必要。
+
diff --git a/mediator-pattern/main.go b/mediator-pattern/main.go
new file mode 100644
index 0000000..17661c7
--- /dev/null
+++ b/mediator-pattern/main.go
@@ -0,0 +1,27 @@
+package main
+
+import "fmt"
+
+// 中介者接口
+type IMediator interface {
+	Notify(c IClient) // 接受通知
+}
+
+// 客户端接口
+type IClient interface {
+	Column()
+}
+
+// 具体中介者，定义关联关系
+type Mediator struct {
+	From IClient
+	To   IClient
+}
+
+func (m *Mediator) Notify(c IClient) {
+	// 会通知所有
+}
+
+func main() {
+	fmt.Println(1)
+}