观察者接口通过模板参数自动推导事件类型，以事件结构体为模板参数实现类型安全的 Subscribe；避免虚函数重复声明，用 std::type_index 索引、副本遍历防迭代器失效，禁止构造函数中注册 this。
观察者接口如何用模板参数自动推导事件类型
传统观察者模式要为每种事件定义单独的接口，比如 OnUserLogin、OnFileSaved，导致大量重复虚函数声明。模板元编程的关键是把事件类型本身作为模板参数，让编译器在实例化时生成对应签名——不是靠继承多态，而是靠函数对象类型擦除 + std::function 适配。
实际做法是：观察者基类不带虚函数，只提供一个泛型注册接口 Subscribe，它接受任意可调用对象（lambda、函数指针、绑定对象），并用 std::type_index 对事件类型做运行时索引。但注意：不能直接用 decltype(event) 作模板参数，因为事件对象可能未构造；应统一用事件类型的别名，例如 struct UserLoginEvent {};，再以 Subscribe<userloginevent>(...)</userloginevent> 显式指定。
- 必须显式传入事件类型模板参数，否则编译器无法推导回调签名
- 回调函数形参必须严格匹配事件类型的 const 引用，如
void(const UserLoginEvent&)，否则std::function构造失败 - 避免在
Subscribe内部做类型擦除转换（如std::any），会引入额外开销和 typeid 比较成本
如何避免信号触发时的迭代器失效问题
观察者列表通常是 std::vector 或 std::list 存储回调，但在通知过程中允许观察者自行注销（Unsubscribe）——这会导致正在遍历的容器结构改变，引发迭代器失效甚至崩溃。
最稳妥的做法是：触发前先拷贝当前活跃观察者的句柄（如 std::shared_ptr 或 raw 指针），再遍历副本执行回调。这样原始容器可安全修改，且避免锁竞争（如果多线程场景下还用了 mutex，则更需注意 lock scope 范围）。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 不要在
for (auto it = list.begin(); it != list.end(); ++it)中调用Unsubscribe - 拷贝开销可控：现代编译器对小 lambda 和
std::function有 RVO 优化，且多数场景观察者数量有限 - 若用
std::list并依赖erase返回下一个迭代器，仍需加锁，不如副本方案清晰
模板参数包展开时如何处理不同事件类型的异构存储
想支持多种事件类型共存于一个观察者管理器中，常见误区是试图用变参模板 template<typename... events></typename...> 一次性定义所有类型。这会导致类模板膨胀、无法动态增删事件类型，且每个实例只能处理预定义的那组事件。
正确路径是分离「事件类型注册」和「观察者存储」：管理器本身不模板化事件，而用 std::unordered_map<:type_index std::vector auto>>></:type_index>（C++20 后可用 std::any 配合 std::function 类型擦除）。但注意 const auto& 不合法——必须用具体类型，所以实际存储的是 std::function<void void></void> 加运行时 static_cast，或更推荐：每个事件类型对应独立的 std::vector，用 type_index 做键，值为 std::vector<:function t>> </:function> 的指针（用 std::unique_ptr 管理）。
- 不要尝试用
std::variant存储不同事件的回调，它要求所有类型已知且数量固定 -
std::type_index(typeid(T))是唯一可靠跨编译单元的类型标识，比字符串拼接安全 - 若事件类型含模板参数（如
NetworkEvent<int></int>），需确保模板实参完全一致，否则typeid视为不同类型
为什么不能在构造函数里自动注册 this 指针
有人想让被观察对象在构造时自动调用 observer.Subscribe<t>(*this)</t>，看似省事，但这是严重隐患：此时派生类构造函数尚未执行，this 指向的是基类子对象，虚函数表未就位，若回调中调用虚函数会调用基类实现或崩溃。
更隐蔽的问题是生命周期：观察者管理器可能持有 this 的裸指针，而被观察对象还没构造完就可能被析构（比如构造抛异常），导致悬挂指针。
- 注册必须发生在对象完全构造之后，典型位置是工厂函数返回后、或初始化列表完成后的成员函数中
- 若必须自动注册，应使用
std::shared_ptr管理被观察对象，并在构造完成后由 weak_ptr 升级为 shared_ptr 再注册 - 禁止在基类构造函数中调用任何可能被重写的虚函数，包括间接调用（如通过回调触发）
真正麻烦的不是语法怎么写，而是事件生命周期与观察者生命周期的耦合点——比如一个事件对象在回调执行中途被销毁，或者观察者在通知中途注销自己。这些边界情况没法靠模板自动解决，得靠明确的 ownership 约定和文档约束。
