Go 中不应使用 Mediator 接口，因其导致类型丢失、字符串事件难维护；应改用函数字段或 channel 实现类型安全、内聚且易测试的协作机制。
Go 语言没有类继承和接口实现的强制约束，也不鼓励用“模式”套代码，所以直接照搬 Java 风格的中介者模式（Mediator Pattern）往往会导致过度设计、接口膨胀、运行时反射滥用——这在 Go 里既不必要，也难维护。
为什么 Mediator 接口在 Go 里通常是个坏主意
很多教程一上来就定义 type Mediator interface { Notify(sender interface{}, event string) }，看似抽象，实则埋坑：
-
sender interface{}让类型信息丢失，编译期无法检查谁该发什么事件 - 事件名用
string，拼错无提示，重构困难，IDE 不支持跳转 - 所有组件都得持有
Mediator接口，但 Go 中更自然的协作方式是函数回调或 channel 通信 - 最终你会发现：这个接口只被一个 struct 实现，且所有方法都在同一包内调用——那接口纯属冗余
用函数字段替代中介者接口更符合 Go 习惯
把“通知逻辑”作为字段注入，而不是抽象成接口。组件之间不依赖中介者类型，只依赖具体行为：
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
type ChatRoom struct {
onMessage func(user string, msg string)
}
<p>func (c *ChatRoom) Broadcast(user, msg string) {
if c.onMessage != nil {
c.onMessage(user, msg)
}
}</p><p>// 使用时直接传闭包，逻辑内聚、类型安全、无额外抽象
room := &ChatRoom{}
room.onMessage = func(user, msg string) {
log.Printf("[%s] %s", user, msg)
// 这里可以更新 UI、写 DB、推 WebSocket……
}
room.Broadcast("alice", "hello")- 避免接口层、避免类型断言、避免
interface{}传递 - 测试时可轻松替换
onMessage为 mock 函数 - 如果后续需要多个响应者，改用
[]func(...)或chan即可，无需改接口
当状态协调变复杂时，用 struct + channel 显式建模
真正需要“中介者”语义的场景，往往是多个 goroutine 协作（如聊天室成员管理、游戏房间同步、工作流状态机）。这时应显式封装状态和通信机制，而非模拟 OOP 的“对象间解耦”：
立即学习“go语言免费学习笔记（深入）”；
type Room struct {
users map[string]*User
updates chan updateEvent // 类型安全的事件通道
mu sync.RWMutex
}
<p>type updateEvent struct {
Kind string // "join", "leave", "msg"
User *User
Msg string
}</p><p>func (r *Room) Run() {
for e := range r.updates {
switch e.Kind {
case "join":
r.mu.Lock()
r.users[e.User.ID] = e.User
r.mu.Unlock()
case "msg":
// 广播给所有在线用户（可加过滤逻辑）
}
}
}-
updateEvent是具体类型，不是interface{}或string -
Run()方法明确表达了“中介逻辑”的生命周期和边界 - 所有状态变更走
updates通道，天然串行、可追溯、易调试 - 外部调用方只需
room.updates ，无须知道内部如何处理
真正的难点不在“怎么套模式”，而在于判断：当前逻辑是否真的需要一个中心协调点？还是只是把几个函数拆开命名、再用一个空接口粘起来？Go 的简洁性，恰恰来自克制地拒绝抽象。
