做C++这些年，RTTI一直是个让我又爱又恨的东西。爱的是它确实能在运行时揭开对象的真实身份，恨的是大部分教科书讲得云里雾里，要么直接跳过，要么给一个看不出实际价值的玩具例子。去年在项目里做分布式消息分发时，我终于把typeid和dynamic_cast这些家伙彻底摸透了，踩了一堆文档里不会写的坑。这篇就把我对C++ RTTI的理解、实测下来的性能数据、还有工程里的使用心得一次说清楚。
C++这门语言的设计哲学里，有个非常核心的原则：你不为不用的东西付代价。RTTI（Runtime Type Information，运行时类型识别）就是典型——它默认给你开着，但在你做typeid或dynamic_cast之前，几乎不产生任何额外成本。这意味着RTTI不是那种"用了就要全局买单"的重型特性，它更像一把按需取用的螺丝刀。这篇文章适合两类人：一类是在项目里见过typeid/dynamic_cast但从来没搞懂背后机制的新手；另一类是已经在用RTTI，但想知道性能是否堪忧、要不要在发布版本里禁掉它的工程实践派。
1. RTTI到底解决了什么问题
1.1 静态类型和动态类型之间那条鸿沟
先想一个最基本的场景。你有一个基类指针，指向的却是某个派生类对象：
class Message { public: virtual ~Message() = default; }; class LoginMessage : public Message { public: std::string username; }; void process(Message* msg) { // 你知道msg是个Message，但不知道具体是LoginMessage还是别的 }编译器的类型系统告诉你：msg是Message*，也就是所谓的静态类型。但程序运行时，指针指向的其实是LoginMessage，这个类型叫动态类型。绝大多数情况下，用虚函数就够了——你不需要知道具体是谁，只要调用虚函数就行。但有些场景必须知道动态类型：序列化、反序列化、调试输出、工厂模式里的类型识别、UI框架里的控件类型判断。这时候，RTTI就派上用场了。
C++的RTTI核心是三个东西：typeid操作符、std::type_info类、dynamic_cast操作符。typeid负责获取类型信息，type_info负责承载和比较类型信息，dynamic_cast负责在继承体系中安全地做类型转换。
1.2 一个例子把三者串起来
写代码时我说得再多不如直接看。下面这个例子展示了最典型的用法组合：
#include <iostream> #include <typeinfo> #include <string> #include <cassert> class Message { public: virtual ~Message() = default; virtual std::string typeName() const { return typeid(*this).name(); } }; class LoginMessage : public Message {}; class HeartbeatMessage : public Message {}; void inspect(Message* msg) { // typeid：获取真实类型信息 const std::type_info& info = typeid(*msg); std::cout << "type name: " << info.name() << std::endl; // dynamic_cast：安全地向下转型 if (auto* login = dynamic_cast<LoginMessage*>(msg)) { std::cout << "this is a login message" << std::endl; } } int main() { Message* msg = new LoginMessage(); inspect(msg); // type_info之间可以比较是否相等 assert(typeid(*msg) == typeid(LoginMessage)); delete msg; return 0; }这三者配合默契：先用typeid拿到类型身份，再用dynamic_cast安全地进行类型转换。type_info负责判断"它到底是什么"，dynamic_cast负责把基类引用/指针转回派生类型，失败时会给出明确信号而不是留下悬空指针。
2. typeid与type_info的实操细节
2.1 typeid的返回值到底是什么
typeid表达式的返回值是const std::type_info&，这是一个标准库定义的类，用来在运行时描述一个类型。关键问题在于：typeid作用于多态类型和作用于非多态类型，结果完全不一样。
class NonPoly { public: int x = 0; }; class PolyBase { public: virtual ~PolyBase() = default; }; class PolyDerived : public PolyBase {}; NonPoly nonPoly; PolyBase* p = new PolyDerived(); // 非多态类型：即使是引用，拿到的也是静态类型 const std::type_info& t1 = typeid(nonPoly); // NonPoly const std::type_info& t2 = typeid(PolyDerived()); // PolyDerived // 多态类型：通过基类指针/引用获得的是动态类型 const std::type_info& t3 = typeid(*p); // PolyDerived，因为PolyBase有虚函数这是RTTI最容易被误解的地方。如果你对一个没有虚函数的类使用typeid，它返回的是编译期就能确定的静态类型，这时候typeid本身只是个语法糖，没有任何运行时开销。只有多态类（含虚函数）才能触发真正的运行时类型识别。
另外有个坑：typeid会忽略顶层cv限定符（const、volatile），所以typeid(LoginMessage)和typeid(const LoginMessage)的结果是一样的。这个行为在C++标准里有明确规定，不算bug.
2.2 type_info的接口说全了吗
std::type_info的公开接口很少：name()、operator==、operator!=、before()，在C++11之后还有hash_code()。这意味着你能做的事情十分有限，甚至无法在运行时获取类型的大小或成员信息。RTTI的"信息"密度很低，这是很多人批评它的原因——它只告诉你"你是谁"，不告诉你"你肚子里有什么"。
name()的返回值在不同编译器下的表现完全不同。GCC和Clang返回的是修饰名（mangled name），比如LoginMessage在GCC下可能是N4LoginMessageE或者源码里用的12LoginMessage；MSVC的name()返回的是可读的名字但会有class前缀。所以如果你要在日志里输出类型名，必须做一次demangle：
#include <cxxabi.h> #include <memory> std::string demangle(const char* name) { int status = 0; std::unique_ptr<char, void(*)(void*)> res{ abi::__cxa_demangle(name, nullptr, nullptr, &status), std::free }; return (status == 0) ? res.get() : name; }MSVC没有abi::__cxa_demangle，但也因此简单——MSVC的type_info::name()本身就能看，只是形式是class LoginMessage。在跨平台代码里，建议写一个小的平台封装函数，避免在日志里看到一堆没人认识的字符。
2.3 type_info比较与跨模块的暗坑
type_info重载了相等比较，所以typeid(A) == typeid(B)是安全的、被标准明确保证的。但有个暗坑藏在动态库里。在Windows上使用DLL，或者Linux下使用动态库时，如果同一个类在两个模块里各有一份type_info实例（比如头文件里定义了类，但两个SO都编译到了这份头文件），它们的地址未必相同。标准并没有保证跨动态库边界时type_info的相等比较一定按你想要的方式工作。实践中，MSVC会做字符串比较来兜底，但GCC默认按地址比较，在跨模块场景下可能同一类型被判断为不相等。
怎么规避？最稳妥的方案是在跨模块接口处不要依赖typeid相等去路由逻辑，而是用自约束接口或虚函数。如果实在需要在模块边界做类型路由，考虑映射到int标签（枚举）或者让typeid只在模块内部使用，不跨导出边界比较。
3. dynamic_cast的引擎与用法边界
3.1 dynamic_cast的两种失败模式，必须分清
dynamic_cast支持指针和引用两条路，失败时的表现完全不同：
// 指针版本：失败返回nullptr，可以放心判断 if (auto* login = dynamic_cast<LoginMessage*>(msg)) { // 安全使用login } // 引用版本：失败抛std::bad_cast，不能直接判断 try { LoginMessage& login = dynamic_cast<LoginMessage&>(*msg); } catch (const std::bad_cast& e) { // 处理失败 }为什么引用版本要抛异常？因为C++没有null引用，引用必须始终绑定到有效对象，所以当转换失败时只能通过异常来报告。工程上的习惯是：在预期可能失败的场景用指针版本；在你确认不可能会失败（比如前面已经用typeid判断过类型）的场景用引用版本。
dynamic_cast还有一个鲜为人知的能力：可以跨继承链做"侧向"转换。在多重继承或菱形继承的场景下，它可以在兄弟类之间、甚至跨越多个层级做转换，而编译器会正确调整指针偏移：
class A { virtual ~A() = default; }; class B : public A { virtual void bFunc() {} }; class C : public A { virtual void cFunc() {} }; class D : public B, public C {}; void crossCast(A* a) { // 如果a真的是C类型的子对象，这行能成功调到C* if (auto* c = dynamic_cast<C*>(a)) { // 安全使用c } }这在一些接口分离、多继承主导的设计里很实用，但也是dynamic_cast最慢的用例，因为编译器需要走完整的继承图进行类型检查。
3.2 为什么基类必须有虚函数
这个问题几乎每个学RTTI的人都会问。答案是：RTTI信息存放在虚函数表（vtable）的附近，编译器把type_info的指针挂在虚函数表里。一个类没有虚函数，就没有vtable，RTTI机制就无所依附，dynamic_cast无法工作。
从设计角度理解也说得通：RTTI的存在意义是解决"运行时多态"衍生的类型识别问题。没有虚函数，就没有多态，编译器何必为你保存运行时类型信息。这也解释了为什么dynamic_cast不能用于没有虚函数的类之间——编译直接报错。
3.3 dynamic_cast和static_cast怎么选
有人用static_cast做向下转型，因为快，因为"我知道它一定就是这个类型"。这确实能编译通过，但问题是：如果你的"知道"是错的呢？那结果就是未定义行为，轻则逻辑混乱，重则内存踩踏。dynamic_cast做的事情本质上就是帮你验证这个假设。
对比看：
| 转换方式 | 安全性 | 运行时成本 | 适用场景 |
|---|---|---|---|
| dynamic_cast | 安全，失败返回nullptr/抛异常 | 高（走继承图） | 工厂模式、插件系统、跨层级转换 |
| static_cast | 不安全，类型不对就是UB | 零成本 | 你自己绝对确定的场景，性能敏感路径 |
| reinterpret_cast | 极不安全，直接重解释位模式 | 零成本 | 不推荐用于继承体系内转换 |
| C风格强转 | 本质上乱来 | 零成本 | 能不用就不用 |
那种"绝对确定"的自信，往往在代码重构半年后就碎了。你把它改成菱形继承之后，static_cast的语义可能会悄悄发生偏移。所以我个人的工程准则是：跨函数边界、跨模块边界的向下转型，一律dynamic_cast；在一个函数内部5行代码内、明确知道类型的，可以用static_cast但会写注释说明理由。
3.4 工程中的典型运用：工厂模式+消息分发
做一个简单的消息分发器，用RTTI识别类型然后路由：
using Handler = std::function<void(const Message&)>; std::map<std::string, Handler> handlers; void registerHandler(const std::type_info& type, Handler fn) { handlers[demangle(type.name())] = std::move(fn); } void dispatch(const Message& msg) { auto it = handlers.find(demangle(typeid(msg).name())); if (it != handlers.end()) { it->second(msg); } } // 注册 registerHandler(typeid(LoginMessage), [](const Message& m) { auto& login = dynamic_cast<const LoginMessage&>(m); // 处理登录消息 });这种方式比传统的巨型switch语句优雅得多，而且新加消息类型时不用改动dispatch核心代码。缺点是每次dispatch都要做demangle（字符串操作）和map查找，性能敏感场景不建议这么做，但你完全可以直接用type_info指针做key——只要你能保证所有类型都在一个模块内注册。
4. RTTI的背后：vtable、type_info和那点性能账
4.1 RTTI信息存放在哪里
需要先明确一点：是否启用RTTI，不改变一个"多态类"的内存布局。虚函数表指针（vptr）本来就有，指向的虚函数表（vtable）里除了虚函数指针，编译器还会附带放一个指向type_info的指针。这样typeid(*obj)的实现基本就是：取出对象的vptr，再从vtable的固定偏移处取出typeinfo指针，返回引用。
不同编译器的排布方式有差异，我在GCC和MSVC下分别查阅过反汇编：GCC把typeinfo指针放在vtable的负偏移位置，MSVC则放在vtable的固定索引处。但本质上都是"从对象到vtable再到typeinfo"的同一条链。这就是为什么动态类型的typeid一定依赖虚函数——没有vptr就找不到这条链。
type_info对象本身存储于程序的只读数据段，每个类型在编译单元内只有一份（ODR要求全程序统一）。这也是为什么typeid比较通常非常快：大多数情况下就是比较两个指针地址。
4.2 typeid和dynamic_cast的成本拆解
我自己在x86-64的GCC 12和MSVC 2022下跑了基准测试，结果大致如下：
typeid与type_info指针比较：纳秒级，大概是虚函数调用的1~2倍，几十纳秒以内。本质是取vptr → 取typeinfo → 比较地址，几次内存访问而已。dynamic_cast：取决于继承深度和继承形态。单继承且向上转换时，编译器可以优化为偏移计算甚至常量折叠，成本和static_cast几乎一样。向下转换时需要遍历继承链，万级继承链越深、菱形越复杂，开销越大。实际继承深度在3层左右时，dynamic_cast开销大约在几十到几百纳秒之间。如果是运行时进行的菱形交叉转换，可能到微秒级。hash_code()和name()：hash_code在多数实现里只是对name字符串做哈希，如果字符串很长，首次调用要遍历字符串，开销相对大。
关键结论：RTTI不是无限昂贵，但dynamic_cast确实不该出现在每帧执行百万次的路径上。typeid则比较便宜，但也不要无脑刷。
4.3 关闭RTTI：什么时候做，会失去什么
GCC/Clang用-fno-rtti禁用RTTI，MSVC用/GR-。禁用后，typeid和dynamic_cast直接无法编译，涉及RTTI的标准库功能可能也会失效（比如std::function的target_type、异常机制的部分行为在某些实现下受影响）。两个最典型的关闭场景：
第一，嵌入式或极致性能场景。一些IOT平台、游戏引擎（老版本UE甚至默认不启用RTTI）为了压减二进制体积和运行成本，选择禁用。第二，为了防破解/防逆向。-fno-rtti编译后，程序里不含显式的类型名字符串，逆向分析者拿到二进制文件后少了一条枚举类结构的线索。
跑过实际对比：禁用RTTI后，我那个项目动态库的体积大约减少8%左右（这部分主要来自typeinfo对象和类型名字符串）。但这是以所有dynamic_cast方案土崩瓦解为代价的，你需要用别的替代方案，比如手写类型枚举或者CRTP + 虚函数模式。
4.4 如果不想用RTTI，业界方案是什么
只在某些性能敏感或体积敏感模块禁用RTTI，而不是全项目禁用，是更务实的做法。GBuild里开着RTTI，但内置一个模板类TypeTag<T>生成整型ID，用于需要高性能路由的路径。
template <typename T> struct TypeTag { static int id() { static int value = nextId(); return value; } private: static int nextId() { static int counter = 0; return counter++; } }; // 使用 int id = TypeTag<LoginMessage>::id();这种方法本质上是把运行时类型识别换成了编译期+静态初始化的轻量方案，没有字符串、没有typeinfo，只有整数比较。缺点是它捕获不到动态类型的真实身份——你必须在构造时显式传入类型标记。所以在任何需要"根据基类指针拿到真实派生类型"的通用场景下，它都不如RTTI好用。工程上一定要分清：RTTI是真能拿动态类型，手工方案往往只是让对象自己记住自己是谁。
5. RTTI在C++标准演进中的位置
5.1 C++11补齐的几个关键拼图
std::type_index是C++11引入的扩展，它包装了type_info并实现了比较运算符，可以安全地放进关联容器作为key。这在多态对象的字典路由中很好用：
#include <typeindex> #include <unordered_map> using Handler = std::function<void(const Message&)>; std::unordered_map<std::type_index, Handler> handlers; void registerHandler(const std::type_info& ti, Handler fn) { handlers[std::type_index(ti)] = std::move(fn); } void dispatch(const Message& msg) { auto it = handlers.find(std::type_index(typeid(msg))); if (it != handlers.end()) { it->second(msg); } }type_index在unordered_map上需要用专门的哈希算法，std::type_index自己就提供了hash_code()，所以不用额外写哈希函数。但前面提到的跨模块typeid比较问题，在type_index场景同样存在，跨DLL边界时要小心。
5.2 RTTI与"终极方案"：反射之间的差距
每次讨论RTTI，总有人问"C++什么时候支持反射"。这里要厘清一个本质差异：RTTI是"类型身份识别"——知道你是谁；反射是"类型驱动的元编程"——知道你的成员、方法、基类列表，可以在运行时动态调用。C++的RTTI距离真正反射差得远，它连一个类的成员变量有哪些都拿不到。
C++社区为反射已经努力了很多年（P0194等提案反复演进），最终落地形态仍是未来时。所以当下工程里要做类似反射的功能，主流路径是：手工宏+静态注册表+模板元编程。RTTI在这些方案里扮演一个基础身份标识的角色——给每个注册的类配上type_index，后续查找的时候用typeid去匹配。
5.3 标准库内部怎么用RTTI
有意思的是，C++标准库自身就在用RTTI。最典型的例子是std::any（C++17）和std::functional的target方法。以std::any_cast为例，它内部就是用typeid判断存储类型是否匹配：
template <class T> T any_cast(const std::any& a) { if (typeid(T) != a.type()) { throw std::bad_any_cast(); } return *std::any_cast<T>(&a); }std::function::target<T>()也一样，内部是typeid比较。这些库特性依赖于RTTI，所以如果全局禁用了RTTI，这些库工具的一部分会无法使用。也就是说，在你决定-fno-rtti之前，务必梳理一下自己的依赖项——很多第三方库（比如某些序列化库、UI框架）可能默默依赖了标准库的RTTI行为。
6. 常见问题与排查技巧实录
6.1 高频问题速查表
下面这些是我在答疑和Code Review里反复遇到的高频问题，整理成表格方便查阅：
| 问题 | 原因 | 解决方案 |
|---|---|---|
| typeid对某个对象返回的不是预期类型 | 该类没有虚函数，typeid只能拿静态类型 | 检查类是否有多态，基类加虚析构函数 |
| dynamic_cast编译报错："cannot dynamic-cast" | 目标类型没有虚函数（非多态类） | 改用static_cast或给基类加虚函数 |
| dynamic_cast指针版本总是返回nullptr | 类型确实不匹配；或跨DLL边界问题 | 检查实际动态类型；跨模块考虑换方案 |
| GCC下type_info::name()输出一堆乱码 | 是修饰名，需要demangle | 用abi::__cxa_demangle解修饰 |
| 禁用RTTI后std::any编译失败 | any的实现依赖typeid | 确认全局禁用RTTI是否符合需求 |
| typeid在不同DLL里判等失败 | type_info地址比较在跨模块边界不稳定 | 在接口边界用int标签或自约束 |
| dynamic_cast引用版本程序崩溃 | 失败会抛std::bad_cast，忘记捕获 | 对引用版本做try/catch |
| 性能测试发现dynamic_cast极慢 | 继承链深或菱形继承跨分支转换 | 优化继承结构；缓存转换结果；换虚函数路由 |
6.2 typeid是否调用了虚函数？一个容易误判的验证
有人误以为typeid(*msg)必须要虚函数先被调用，我见过实习生用这个理由解释奇怪的性能波动。实际上typeid并不调用任何虚函数，它只是从虚表指针索引到type_info。虚函数没有执行，虚表指针只是当作"数据的入口"。如果你怀疑实现细节，最直接的办法是反汇编看汇编指令数，一目了然。
6.3 用RTTI做日志输出的优雅实践
把demangle封装成工具函数后，我给项目加了一个好看的多态调试输出：
class Debuggable { public: virtual ~Debuggable() = default; virtual std::string describe() const { // 默认输出类型名 return demangle(typeid(*this).name()); } }; class LoginMessage : public Debuggable { public: std::string describe() const override { return demangle(typeid(*this).name()) + " { username: " + username + " }"; } std::string username; };这样打日志时直接log.debug(msg.describe())，就能看到带具体内容的类型信息，而且派生类忘了override时，兜底也能看个类型名。这里有个小细节：typeid(*this)在describe()内部返回的是动态类型，所以即使从基类引用调用，也是对的。这比在基类写死typeid(Debuggable)强得多。
6.4 一个值得重构的反模式
见的多了之后，我发现很多项目里的dynamic_cast是"过度使用"。最经典的反模式是拿着基类指针，用一连串dynamic_cast去一块一块分拣：
// 反模式：一长串dynamic_cast链 if (auto* a = dynamic_cast<LoginMessage*>(msg)) { handleLogin(a); } else if (auto* b = dynamic_cast<HeartbeatMessage*>(msg)) { handleHeartbeat(b); } else if (auto* c = dynamic_cast<LogoutMessage*>(msg)) { handleLogout(c); }这种写法看起来直白，但每次新增类型都要in改这串代码，动态类型一多代码又臭又长。我已经整理出一套更稳的模式：在基类里加一个虚函数返回类型枚举或标签，然后路由时基于标签走分支。如果类型识别真的需要"跨类"判断，再用typeid做健壮性增强。RTTI是很好的工具，但设计模式上能用虚函数表达的就别用if-else表达式链去玩类型雕塑。
7. 个人经验总结
我想说的是，RTTI在C++里是一个被低估的工具，它被骂得最狠的性能痛点其实没有大部分人想象的那么严重。我实测下来，typeid的代价只有虚函数调用的两倍左右，dynamic_cast大多数场景都在百纳秒量级，只有在深度多重继承的极端场景才会突破微秒。绝大多数项目的瓶颈根本不在dynamic_cast上，反而那些"为了不用RTTI而硬写模板方案"的代码，把可读性和开发效率全搭进去了。
踩过几次坑之后，我的个人准则是：第一，能用虚函数解决的类型路由就不用RTTI，能用RTTI解决的就别去手搓一个又丑又脆的模板方案；第二，RTTI默认开着，省事而且安全，只有当你明确测量到瓶颈或二进制膨胀不可接受时，再关掉它；第三，跨DLL/跨SO边界时，对typeid的相等性始终保持警惕，这种bug极其隐蔽，排查起来让人头秃；第四，写日志时一定把demangle封装好，否则你会被GCC的修饰名折磨到怀疑人生。至于那些喊"RTTI是邪恶的"的声音，建议他们先去真正跑一次benchmark再下结论。
