用std::function+std::vector实现事件总线需用shared_ptr/weak_ptr避免悬挂指针，单线程用vector即可，多线程需先拷贝回调列表再调用；取消订阅返回可调用句柄；泛型总线慎用type_index，推荐专用总线或hash_code键合unordered_map。
怎么用 std::function + std::vector 实现轻量事件总线
核心是把回调存起来，触发时遍历调用——不依赖第三方库，C++11 起就能写。关键不是“能不能”，而是“怎么避免悬挂指针”和“线程安全怎么妥协”。
常见错误现象：std::bad_function_call 抛出、程序崩溃在 notify() 里、订阅者析构后还被调用。
- 用
std::shared_ptr包裹可调用对象（比如std::shared_ptr），或用weak_ptr管理生命周期，避免裸指针/引用悬挂 - 订阅时返回一个
std::function类型的取消句柄，内部调用erase；别直接暴露容器迭代器（容易失效） - 如果只在单线程用，
std::vector足够；多线程场景下，至少给容器加mutable std::mutex，但别锁整个notify()——先拷贝回调列表再解锁，再逐个调用
示例：订阅时返回取消函数
auto sub = bus.subscribe<int>([](int x) { std::cout << x; });
sub(); // 取消订阅
为什么不能直接用 std::map<std::type_index, ...> 做多类型事件
可以存，但类型擦除成本高，且 std::type_index 不支持跨编译单元稳定比较（尤其开启 LTO 或不同 DLL 时）。更实际的问题是：你没法静态检查某个事件类型是否被注册过，调试时只能靠运行时报错。
使用场景：需要统一管理多种事件，但又不想为每种类型写单独总线实例。
- 改用
std::unordered_map<const void*, std::any>，用typeid(T).hash_code()当 key，比std::type_index更可靠 - 或者干脆放弃“泛型总线”，为高频事件类型（如
MouseClickEvent、ConfigReloaded）各建一个专用总线类，类型安全、无运行时开销 - 若必须泛型，确保所有事件类型定义在同一个翻译单元，或用
constexpr字符串哈希替代type_index
std::function 捕获 lambda 导致内存泄漏的典型条件
不是 std::function 本身泄漏，而是它捕获了堆对象（比如 this）且没被及时取消订阅。只要对象销毁了，总线里还留着对它的引用，下次通知就踩内存。
常见错误现象：程序退出前出现 double free、ASan 报 heap-use-after-free、断点停在 lambda 体里但 this 是野指针。
- 成员函数订阅必须显式传
shared_from_this()，且类继承std::enable_shared_from_this - 避免捕获局部变量地址（比如
&local_var），除非你能 100% 确保回调执行时机早于局部作用域结束 - 用
std::weak_ptr包裹this，在 lambda 内部先lock()，失败则直接 return —— 这是最稳妥的弱引用模式
要不要支持同步/异步通知？关键看调用上下文
异步通知不是“加个 std::async”就行。真正要问的是：通知者能否承受延迟？被通知者是否允许重入？事件处理是否可能阻塞？
性能影响：同步通知零额外开销；异步通知涉及线程调度、队列锁、内存分配，延迟不可控，且容易引发优先级反转。
- GUI 事件（如按钮点击）必须同步，否则 UI 响应卡顿或状态错乱
- 日志、埋点类事件适合异步，但要用无锁队列（如
moodycamel::ConcurrentQueue），别用std::queue + mutex - 如果业务逻辑本身已在线程池中运行，再套一层异步只会增加上下文切换，不如直接同步调用
复杂点永远在生命周期管理——哪怕你把所有技术细节都做对了，只要有一个订阅者忘了取消，或者用错了 shared_ptr 的构造方式，整条链就不可靠。
