无模板静态调度：基类存储类型标签的实现方案可行性问询

这个模式在通用教程中很少提及，但在游戏引擎、高频交易等极致性能要求的领域是非常常见的实践，通常被称为「类型标记分发」，本质是手动实现了一套精简版的运行时类型识别与分发逻辑，你的优劣势总结基本准确。

1. 极致性能场景下的额外弊端 #

• 分支预测开销：switch本质是多分支跳转，当传入的派生类类型完全随机没有规律时，CPU分支预测失败的概率会远高于常规虚函数调用。常规虚函数是单间接跳转，现代CPU对这类固定模式的间接跳转预测准确率非常高，只有当类型分布高度可预测时switch的性能优势才会保留。
• 指令缓存命中率下降：每新增一个多态接口都需要重复编写完整的switch分支逻辑，相同的类型判断代码会散落在各个函数中，最终编译出的二进制体积远大于虚函数方案，反而会降低指令缓存的命中率，抵消掉调度本身的性能收益。
• 编译器优化受限：虚函数方案下，编译器在编译期能推导实际类型的场景会自动做去虚拟化优化，而手动编写的switch分支很多时候不会被编译器识别合并，反而可能生成冗余的跳转指令。

2. 性能是否理论上更优 #

你的测试结果不是偶然，该方案在大多数场景下确实性能优于常规多态和dynamic_cast：

• 理论层面，该方案省去了访问虚表指针、读取虚表条目两次内存访问开销，static_cast是纯编译期操作，完全没有运行时成本，比需要做RTTI查询的dynamic_cast快1~2个数量级。
• 只有在极端场景下性能会反超：当分支预测失败率超过10%时，虚函数的单跳转性能会高于switch的多分支跳转，你可以修改测试用例完全随机传入Foo和Bar实例，就能观测到这个边界效应。
• 内联确实会放大性能差异：switch分支内的函数调用（比如示例中的getValue）非常容易被编译器内联，而虚函数调用只有在去虚拟化成功时才能被内联，所以微基准测试中的性能差距通常会比实际生产场景更大。

3. 容易踩的其他坑 #

• 类型标签赋值错误：如果派生类构造时传错了Type枚举值，static_cast会直接触发未定义行为，不会有任何运行时检查，崩溃原因比虚函数方案难排查数倍。
• 漏写分支无提示：即使你当前派生类数量固定，只要后续新增派生类，所有用到switch分发的地方漏加case都会走到default分支，大概率出现静默的逻辑错误，除非你开启了枚举所有分支必须覆盖的编译警告，否则编译器不会给出任何提示。
• cv限定符不匹配风险：如果Base指针带const/volatile限定符，static_cast时漏写对应的限定符也会触发未定义行为，而虚函数调用完全不需要考虑这个问题。
• 不支持多重继承：如果后续派生类需要引入其他基类，static_cast的地址偏移会计算错误，必须额外处理转型逻辑，而虚函数方案天然支持多重继承。

如果你的场景确实满足派生类固定、类型分布可预测的前提，这个方案是完全可行的，建议开启编译警告强制所有枚举分支必须被覆盖，能规避绝大多数风险。

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