std::type_index可作异构容器类型键，但需规避生命周期（避免临时typeid悬垂）、修饰符（统一用std::remove_cv_t）和哈希器（旧编译器可能未特化std::hash）三类坑。
直接用 std::type_index 做异构容器的类型键是可行的，但必须避开生命周期、修饰符和哈希器这三类坑，否则查不到、崩溃或跨平台行为不一致都是大概率事件。
为什么 std::type_index 能当异构容器的键
std::type_index 本质是 std::type_info 指针的包装，可拷贝、可比较、支持 ==/!= 和 hash_code()，而裸指针或 const std::type_info& 都不行——前者悬垂风险高，后者不可拷贝，std::map 或 std::unordered_map 直接拒编译。
常见错误现象：std::map<const std::type_info t></const> 看似能存，但 typeid(obj) 返回的是临时对象，取其地址就是悬垂指针；std::map<:type_info t></:type_info> 则根本过不了编译。
-
std::type_index构造开销极小，内部只存一个指针，operator==是指针比对，O(1) - 它不依赖模板实例化位置：同一类型在不同 .cpp 文件里生成的
std::type_index仍能正确相等 - 但注意：它不保证跨进程、跨次运行的
hash_code()值一致，不能用于持久化或网络序列化
std::unordered_map<:type_index t> 编译失败？检查哈希器
标准库从 C++11 起已特化 std::hash<:type_index></:type_index>，但部分旧编译器（如 GCC 4.8 或某些 MSVC 低版本）可能未完全实现，导致 std::unordered_map<:type_index t></:type_index> 报 “no matching function for call to ‘hash’”。
立即学习“C++免费学习笔记（深入）”；
实操建议：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 优先用
std::map<:type_index t></:type_index>，省去哈希器适配麻烦，且查找性能差异在绝大多数场景下可忽略 - 若坚持用
std::unordered_map，显式提供哈希器：std::unordered_map<:type_index t std::hash>></:type_index> - 别自己写哈希器去调
ti.hash_code()——它本就是std::hash特化的底层依据，重复封装无意义还易出错
类型修饰符敏感：int 和 const int 是两个键
std::type_index{typeid(int)} 和 std::type_index{typeid(const int)} 不等，哪怕你传的是 const int x = 42;。这是 typeid 的语义决定的，std::type_index 忠实反映它。
使用场景中典型翻车点：
- 工厂注册时用了
typeid(MyClass)，但调用方传了const MyClass&，查find(typeid(const MyClass&))就失败 - 模板函数内写
typeid(T)，当T = const int时，和外部注册的typeid(int)对不上 - 统一约定：注册和查询都用“退修饰后的值类型”，例如统一用
std::type_index{typeid(std::remove_cv_t<t>)}</t>
多态类型识别：别对指针用 typeid(T*)
要识别多态对象的实际类型，必须作用于**对象本身**，而不是指针变量。即用 typeid(*ptr) 或 typeid(obj)，而非 typeid(ptr)。
参数差异很关键：
-
typeid(Base*)永远返回Base*类型信息，跟实际指向谁无关 -
typeid(*ptr)才会触发动态类型查询（前提是Base有虚函数），返回Derived的type_info - 若
ptr为空，typeid(*ptr)会抛std::bad_typeid，务必先判空
异构容器里做运行时分发时，这点最容易被忽略：你以为存的是派生类类型，结果键却是基类指针类型，查表永远落空。
