该用，但仅限fyne、giu等需手动管理生命周期的gui框架；中介者应为独立结构体，持组件弱引用，避免强引window，用方法调用而非channel通信，状态需显式绑定ui渲染。
Go GUI里中介者模式到底该不该用
直接说结论：在标准库 net/http 或命令行工具里，中介者模式基本没意义；但如果你用的是 fyne、giu 或 webview 这类需要手动管理组件生命周期和事件流的 GUI 框架，它确实能帮你把“按钮A点了要改标签B、禁用输入框C、触发后台任务D”这类耦合逻辑拎出来——前提是，你已经意识到组件间直接互相调用正在变成维护噩梦。
用 fyne 实现中介者时，别把 App 或 Window 当中介者
常见错误是让 app.NewApp() 或 window.ShowAndRun() 承担协调职责。它们是框架入口，不是业务逻辑中枢。真正的中介者应该是个独立结构体，持有对各 UI 组件的弱引用（比如用 *widget.Button 指针），并通过方法暴露交互契约。
- 中介者实例应在 UI 初始化完成后创建，而不是在
func main()开头就 new 出来 - 避免在中介者里保存
fyne.Window强引用，否则可能阻碍 GC；用回调函数或事件通道解耦更安全 -
fyne的widget.Button.OnTapped是闭包，直接在里面写业务逻辑会快速膨胀；应只调用中介者的HandleLoginClick()这类语义化方法
为什么不用 channel 而用方法调用做中介者通信
有人试图用 chan struct{} 或 chan event 让按钮发消息、标签收消息——这在 Go GUI 里容易掉进“goroutine 泄漏”和“UI 线程不安全”的坑。Fyne 和 GIU 都要求 UI 更新必须在主线程（即 app.Run() 所在线程）执行，而 channel 收发本身不保证线程上下文。
- 用方法调用（如
mediator.UpdateStatusLabel("loading...")）天然落在当前 goroutine，只要调用方在主线程，就安全 - 若需异步触发（比如点击后发起 HTTP 请求再更新 UI），应在中介者内部用
app.QueueUpdate()（Fyne）或runtime.GuiSync()（GIU）包装 UI 更新操作 - channel 更适合跨域通信（如后台 worker 和 UI 之间），不是组件间协调的首选
giu 下中介者怎么避免重复渲染和状态错乱
giu 是声明式 UI，每帧都重绘。如果你在中介者里存了状态（比如 isProcessing bool），又没在 giu.Layout 中显式绑定，就会出现“点了按钮但按钮没变灰”这种现象。
立即学习“go语言免费学习笔记（深入）”；
- 所有影响 UI 的状态必须作为字段放进中介者，并在
giu.Layout中通过giu.Button().OnClick(...)和giu.Label(mediator.statusText)显式使用 - 不要在
OnClick回调里直接修改全局变量或未导出字段；中介者字段要可导出（首字母大写），否则giu反射读不到 - 复杂状态建议用
sync.Mutex保护，但锁粒度要小——只锁字段赋值，别锁整个 UI 渲染流程
真正难的不是写出中介者结构，而是判断哪部分逻辑值得抽离：UI 布局变化、用户意图聚合、跨组件副作用触发——这些边界稍不注意，中介者就会变成新锅灶。
