为何std::any实现要使用typeid？无RTTI替代方案为何不通用？

这问题问得特别到位！咱们来好好捋一捋背后的逻辑：

首先，RTTI（运行时类型识别）是C++标准原生提供的类型标识机制，typeid返回的std::type_info对象是编译器统一管理的，从设计初衷来说，它就是为了解决运行时类型判断的问题。

早期std::any的实现（包括标准制定阶段的参考实现）选择RTTI主要有两个原因：

• 标准语义契合：std::any的type()方法需要返回const std::type_info&，这本身就和RTTI的设计直接对齐，用原生机制最符合标准的预期行为。
• 可靠性与优化空间：编译器对typeid有大量针对性优化，比如同一翻译单元内的类型比较会直接被优化成常量判断；跨模块场景下，std::type_info的实例通常由编译器统一维护，行为更稳定。而模板静态变量的方案在早期C++版本中，跨DLL/so的唯一性保障还存在边缘场景的问题，不如RTTI成熟。

你这个疑问抓得很准，这里要分场景看：

• 编译期优化：如果编译器能确定两个typeid比较的是同一类型，会直接把typeid(T) == typeid(U)优化成常量true或false，完全不需要运行时计算。而模板静态变量的指针比较，虽然也是简单的地址对比，但它的地址是链接时确定的，默认情况下跨模块的同类型模板静态变量可能会有多个实例，这时候就需要实际的指针比较操作，没法像typeid那样直接被编译期优化掉。
• 编译器特殊处理：std::type_info对象通常存放在只读全局段，编译器会对其比较做特殊优化——比如有些编译器会把同一类型的type_info合并成单个实例，这时候比较操作几乎是零开销。而模板静态变量的合并依赖链接器的优化选项（比如-fwhole-program），默认场景下不一定能享受到这种优化。

这是典型的兼容性+性能的平衡策略：

• 当RTTI开启时，用原生typeid既能满足标准要求（返回有效的std::type_info），又能享受到编译器的优化红利，性能更优。
• 当用户通过-fno-rtti关闭RTTI时，typeid无法正常工作（或者行为受限），这时候就需要降级到模板静态变量的方案——通过每个类型对应的唯一静态变量地址来做类型匹配，保证std::any的核心功能（存储、取出、类型判断）依然可用。
• 另外，模板静态变量方案没法提供std::type_info的额外功能（比如获取类型名称），所以只有在RTTI不可用的情况下，才会放弃type()方法的完整语义，转而用指针比较实现类型匹配。

简单总结：默认用RTTI是因为它是标准原生、可靠且优化充分的方案；模板变量是降级备选，用于不支持RTTI的场景。libc++的这种实现，本质是在不同编译环境下选择最优的类型识别方式。

内容的提问来源于stack exchange，提问作者NoSenseEtAl