不能直接用 std::function + vector 存 observer，因类型擦除导致两次间接调用开销、运行时参数签名不匹配才崩溃，且无法编译期校验；需用模板参数固化签名，配合 requires 约束和静态断言保障类型安全与零开销。
为什么不能直接用 std::function + vector 存 observer？
因为类型擦除带来两次间接调用开销，且无法在编译期校验 notify 参数是否匹配观察者签名。更关键的是：一旦观察者类型变更（比如从 void(int) 改成 void(int, bool)），运行时才崩溃，而模板元编程能提前报错。
真正需要的不是“通用”，而是“接口契约可静态验证 + 无虚函数开销 + 类型安全绑定”。所以得把观察者签名作为模板参数固化下来。
如何用模板参数推导出 observer 的 void(Args...) 签名？
核心是用 std::is_invocable_v + decltype 检查 callable 是否接受指定参数包，但更实用的是直接约束 observer 类型为 Callable<args...></args...>：
template<typename... Args>
struct observer_list {
template<typename F>
requires std::is_invocable_v<F&, Args...>
void subscribe(F&& f) { /* ... */ }
};
注意这里用 requires 而非 SFINAE，避免 enable_if 带来的冗长和错误信息晦涩。实际中建议封装成 trait：is_valid_observer_v<f args...></f>，用于后续事件分发前的静态断言。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 别用
auto参数推导 observer 类型——会丢失 const/volatile 限定，导致const member function绑定失败 - 成员函数指针必须显式绑定 this，推荐用
std::bind_front或 lambda 包装，否则模板推导会失败 - 如果支持 move-only observer（如
std::unique_ptr包裹的 callable），需额外重载subscribe接受右值引用
如何避免每次 notify 都遍历全部 observer？
典型陷阱是把所有 observer 存进一个 std::vector<std::function<void(Args...)>> —— 这等于放弃元编程优势。正确做法是按签名维度做编译期分组：
template<typename... Args>
class event_bus {
// 每个 signature 对应独立的 observer list
std::tuple<observer_list<Args...>...> lists;
};
但这太重。更轻量的是用 std::array 存不同签名的 observer 列表，靠 constexpr if 分支 dispatch。不过最常用且平衡的是单 signature 设计：event<void(int, std::string)>，这样每个 event 类型天然隔离，无需运行时路由。
- 不要试图用
std::any或type-erased容器混存多种签名 observer——这违背“解耦”本意，耦合点转移到类型擦除逻辑里 - 若真需多签名，用 tag dispatch +
std::variant<observer_list<T1>, observer_list<T2>>，但增加复杂度，多数业务场景不值得 - notify 时用
for (auto& obs : observers) obs(args...);即可，现代编译器对 trivially copyable callable 能内联掉大部分调用开销
为什么 operator+= 不适合做订阅语法？
看似优雅：evt += [](int x){/*...*/};，但问题在于：operator 重载无法参与 ADL，也无法约束右操作数类型；更严重的是，它隐式允许重复订阅同一 callable（比如两次传入相同 lambda 地址），而你无法在编译期禁止。
真正可控的方式是显式命名方法：on() 或 subscribe()，并配合 std::same_as 检查是否已存在同地址 observer（仅对函数指针/lambda 有效）；对对象成员函数，则依赖用户传入唯一 token 或用 std::weak_ptr 管理生命周期。
- lambda 表达式每次定义都生成新类型，即使内容相同 —— 所以不能靠类型比较去 dedup，得靠地址或用户显式提供 id
- 若 observer 是类成员函数，必须绑定
this，而this可能是临时对象，要用std::shared_ptr或手动管理 lifetime，这是最容易漏掉的内存安全点 - unsubscribe 几乎总是被忽略，但元编程框架里它必须是
subscribe()的镜像操作，返回可析构的 guard 对象，否则资源泄漏无法静态检查
实际落地时，最难的不是写模板，而是让使用者理解：所谓“通用”，不是“啥都能塞进去”，而是“契约明确后，所有非法用法都在编译时报错”。这点一旦没对齐，框架就会变成调试噩梦。
