中介者模式的核心作用是集中管理通信逻辑，通过将多对多依赖收口到中介者实现协调控制，而非简单解耦；需避免空壳实现、循环依赖与循环引用，且仅适用于通信复杂多变的场景。
中介者模式的核心作用不是解耦，而是集中管理通信逻辑
它不消除对象间的依赖，而是把多对多的依赖关系“收口”到一个中介者里。这意味着：原本 A、B、C 互相调用，现在都只和 Mediator 打交道——A 发消息给 Mediator，Mediator 决定要不要通知 B 或 C，甚至改写内容、延迟转发、加日志。
常见错误是把中介者写成空壳：Mediator::notify() 直接转发给目标对象，没做任何协调逻辑。这等于白加一层，还多一次虚函数调用。
- 真正该做的：在
Mediator::handleEvent()里判断上下文（比如当前状态、权限、数据有效性）再决定响应方式 - 不要让同事类（
Colleague子类）持有对方指针——它们只能持有一个Mediator* - 如果同事类之间仍有大量同构交互（如都调
updateUI()），考虑把这类共性抽成Colleague基类接口，而非在中介者里硬写 if-else
如何避免循环依赖导致编译失败
C++ 头文件里容易出现 Mediator.h 包含 ColleagueA.h，而 ColleagueA.h 又包含 Mediator.h —— 编译器报 "use of undefined type 'Mediator'" 或类似错误。
根本解法是用前向声明 + 指针/引用 + 实现文件分离：
立即学习“C++免费学习笔记（深入）”；
- 在
Colleague.h中只写class Mediator;，成员变量声明为Mediator* m_mediator; - 所有涉及
Mediator成员访问（如m_mediator->send(...)）必须挪到Colleague.cpp，并在该文件顶部#include "Mediator.h" -
Mediator.h可以安全包含所有Colleague头文件，因为它不依赖同事类的具体实现，只调其虚函数接口
std::shared_ptr 还是 raw pointer？选错会影响生命周期
中介者通常长期存在，同事对象可能动态创建销毁。若中介者用 std::shared_ptr<colleague></colleague> 持有所有同事，极易引发循环引用：同事 A 持有中介者指针，中介者又持有 A 的 shared_ptr → A 永远不析构。
更稳妥的做法是反向管理：
- 中介者用
Colleague*（裸指针）或std::weak_ptr<colleague></colleague>存储同事，不参与所有权 - 同事对象的生命周期由外部（如 UI 管理器、场景管理器）控制；销毁前主动调
mediator->remove(this) - 若必须用智能指针，确保中介者不被同事强引用——即同事类中存
Mediator*，而非std::shared_ptr<mediator></mediator>
典型错误示例：ColleagueA 构造时传入 std::shared_ptr<mediator></mediator> 并保存，之后中介者也保存 shared_ptr<colleaguea></colleaguea> → 内存泄漏。
什么时候不该用中介者模式
它适合通信关系复杂、规则多变的模块（如游戏中的技能系统、IDE 的插件事件总线），但以下情况反而增加负担：
- 只有两个对象且交互固定（如按钮点击触发弹窗）→ 直接回调或信号槽更轻量
- 同事类行为高度内聚、几乎不与其他类通信 → 强行塞进中介者只是制造间接层
- 性能敏感路径（如每帧调用数十次的渲染逻辑）→ 虚函数+指针跳转开销明显，且难以 inline
- 团队不熟悉该模式，或代码审查习惯直接追踪调用链 → 后续维护时没人愿查
Mediator::handle()里那堆 switch
最难把握的是边界：中介者该管到哪一层？比如“用户登录成功后刷新头像、更新菜单、推送通知”，这些是否全扔给中介者？还是只让中介者发一个 OnLoginSuccess 事件，由各模块自己订阅？后者更灵活，也更符合单一职责。
