typeid::name() 返回乱码因编译器实现定义，gcc/clang 返回 mangled 名，需 demangle；判断多态类型须确保对象为虚函数类的引用/指针；模板中用 typeid 易触发 odr 违规，应避免；禁用 rtti 后 typeid 和 dynamic_cast 直接编译失败。
typeid 返回的 type_info::name() 为什么总是乱码或缩写？
因为 type_info::name() 的返回值是编译器实现定义的，不保证可读——GCC/Clang 返回的是经过 ABI mangling 的符号名（比如 "N5mylib7WidgetE"），MSVC 虽稍友好但仍有缩写（如 "class mylib::Widget"）。这不是 bug，是标准允许的行为。
- 想看人能读懂的类名，必须调用
abi::__cxa_demangle()（GCC/Clang）或UnDecorateSymbolName()（MSVC）做反解 - 注意：demangle 是非标准 C++，需链接
libstdc++或libc++，且返回的内存需手动free() - 调试时直接用 IDE 的“Evaluate Expression”或 GDB 的
ptype更可靠，别依赖name()输出做日志
如何安全地用 typeid 判断多态对象的真实类型？
必须确保目标对象指针/引用指向的是**多态类型**（即至少有一个 virtual 函数），否则 typeid 在表达式求值时只返回静态类型，不是运行时类型。
- 错误写法：
Base b; typeid(b)→ 永远返回Base，哪怕b实际是Derived对象（切片已发生） - 正确前提：用
Base&或Base*指向Derived实例，且Base有虚函数（哪怕只有虚析构） - 推荐替代方案：优先用
dynamic_cast做类型安全转换，比反复比对typeid更符合意图
typeid 在模板里怎么用才不会意外触发 ODR-violation？
当在头文件中对同一类型多次取 typeid（尤其在内联函数或模板实例化中），可能违反“一个定义规则”（ODR），导致链接期符号冲突或未定义行为。
- 根本原因：
typeid(T)可能生成全局type_info对象，而多个 TU 中定义相同类型时，若编译器未合并这些对象，就出问题 - 规避方式：把
typeid调用封进constexpr函数（C++17 起支持），或改用std::type_identity_t<t></t>+decltype等编译期手段代替运行时识别 - 更实际的做法：避免在模板中直接依赖
typeid(T).name()做逻辑分支；需要类型名时，用宏或特化static constexpr char name[] = "MyType"
RTTI 开关对 typeid 和 dynamic_cast 的实际影响
关闭 RTTI（如 GCC/Clang 加 -fno-rtti，MSVC 加 /GR-）后，typeid 和 dynamic_cast 不再可用——编译器会直接报错，不是运行时报错。
立即学习“C++免费学习笔记（深入）”；
- 常见误判：以为 “
typeid还能用，只是不准”，其实连编译都过不去 - 如果项目禁用 RTTI，又需要类型识别，只能靠手工维护类型 ID（如枚举 +
getTypeId()虚函数）或使用std::any/std::variant（它们内部不依赖 RTTI） - 性能上，开启 RTTI 本身开销极小，主要成本在
dynamic_cast的虚表遍历；但嵌入式或游戏引擎等场景仍常禁用，为的是减少二进制体积和确定性
typeid 的结果是否可信、能否跨编译单元稳定、甚至能不能编译通过，全取决于你是否踩中了 ABI、ODR、多态前提这些隐性条件。 
