可行但需规避三类坑：生命周期（必须用花括号初始化）、类型修饰符（注册与查询须完全一致，推荐std::remove_cvref_t）、哈希器（旧编译器或禁用RTTI时优先用std::map）。
直接用 std::type_index 作异构容器（如 std::map 或 std::unordered_map）的键是可行的，但只要踩中生命周期、类型修饰符、哈希器这三类坑中的任意一个，就会出现“查不到”“崩溃”或“跨编译单元行为不一致”——这不是库的问题，而是对 std::type_index 和 typeid 语义理解偏差导致的。
std::type_index{typeid(T)} 必须用花括号初始化，禁用 &typeid(T)
std::type_index 内部保存的是 const std::type_info*，它靠值构造来安全持有指针。而 typeid 表达式返回的是临时 const std::type_info&，对其取地址（如 &typeid(MyClass)）会立刻生成悬垂指针。
- 错误写法：
factory[&typeid(MyClass)] = value;—— 地址失效后，后续find()或哈希可能触发未定义行为 - 错误写法：
std::type_index(typeid(MyClass))—— 某些编译器会将其解析为函数声明（最 vexing parse） - 正确写法：
std::type_index{typeid(MyClass)}—— 值构造，由type_index自行管理内部指针生命周期 - 多态对象必须解引用：
std::type_index{typeid(*ptr)}，否则typeid(ptr)返回的是指针类型（如Base*），不是实际派生类
注册与查询的类型修饰符必须完全一致
std::type_index 对 const、volatile、引用（&、&&）、指针（*）完全敏感。哪怕只是声明差异，键就不同。
-
std::type_index{typeid(int)}≠std::type_index{typeid(const int)} -
std::type_index{typeid(MyClass)}≠std::type_index{typeid(const MyClass&)} - 模板函数中慎用
decltype(x)：若x是const MyClass&，则typeid(x)带const&修饰，和注册时裸类型不匹配 - 统一建议：注册和查询都基于“退修饰后的值类型”，例如
std::type_index{typeid(std::remove_cvref_t<t>{})}</t>（T为模板参数）或std::type_index{typeid(std::remove_cvref_t<decltype>{})}</decltype>
std::unordered_map<:type_index t> 编译失败？先验证哈希器和 RTTI
标准从 C++11 起已特化 std::hash<:type_index></:type_index>，但 GCC 4.8、MSVC 2013 等旧环境，或项目禁用 RTTI（-fno-rtti）、遗漏头文件时，仍可能报 no matching function for call to ‘hash’。
立即学习“C++免费学习笔记（深入）”；
- 验证方式：
static_assert(std::is_default_constructible_v<:hash>>);</:hash>，失败即需干预 - 若断言失败，显式传入标准哈希器：
std::unordered_map<:type_index t std::hash>></:type_index> - 更稳妥做法：优先用
std::map<:type_index t></:type_index>—— 它只依赖operator<，而std::type_index已完整支持，无需哈希器适配 - 别自己封装哈希器调
ti.hash_code()—— 它本就是标准std::hash特化的底层依据，重复封装无意义且易出错
跨编译单元或动态库时，hash_code() 不稳定是正常现象
std::type_index::hash_code() 的值只保证单次进程内哈希桶分布一致，**不能用于持久化、日志记录、网络传输或跨进程比对**。
- 同一类型在不同进程、甚至同一程序重启后，
hash_code()值都可能变化 - 不要把它当类型唯一 ID 存数据库，或发给其他服务做类型识别
- 真正可靠的判断永远是
==比较，不是哈希值相等 - 若需跨进程稳定标识，应结合
name()+ 白名单校验（但依然不推荐；类型语义应由运行时比较承载）
