多态的隐性成本集中在运行时类型检查开销和向下转型安全风险两方面：前者因虚表访问、类型比对等操作带来性能损耗，后者因类型信任缺失导致异常或竞态问题；更优解是通过虚方法抽象、访问者模式、CRTP或泛型限定等设计手段规避。
多态带来灵活性，也附带隐性成本。核心代价集中在两处：运行时类型检查的开销，以及向下转型时潜在的安全风险。这两者不是孤立问题，而是设计权衡的一体两面。
类型检查不是免费的
Java 的 instanceof 和 C++ 的 dynamic_cast 都需在运行时确认对象真实类型。这涉及访问虚表、比对类型信息、遍历继承链——不是简单判断，而是结构化查询。
- 继承层级越深，检查耗时越长；频繁调用（如循环内）会明显拖慢性能
- C++ 中 dynamic_cast 在无虚函数的类上直接失败，有虚函数但无继承关系时返回 nullptr，这些判断本身就有分支和内存访问成本
- Java 的 instanceof 虽比 dynamic_cast 轻量，但在高吞吐服务中仍可能成为热点，尤其配合大量向下转型时
向下转型不是“还原”，而是“信任”
向下转型成功与否，不取决于语法是否正确，而取决于引用当时是否真指向目标子类实例。编译器无法保证，只能靠程序员控制。
- 没做 instanceof 检查就强转，运行时抛 ClassCastException 或得到 nullptr，程序中断或逻辑错乱
- 即使加了 instanceof，若后续代码修改了对象状态（比如被其他线程替换），检查和转换之间存在竞态窗口
- 转型后调用子类方法，若该方法依赖未初始化的子类字段，仍可能引发 NullPointerException 等间接错误
更安全的替代思路
与其反复检查+转型，不如从设计上减少对具体类型的依赖。
- 把子类特有行为抽象为父类中的虚方法（如 Animal.addBehavior()），由子类各自实现，避免转型调用
- 用访问者模式或双分派，将类型相关逻辑外移到独立结构中，保持类职责单一
- C++ 中可考虑 CRTP 模式，在编译期完成静态向下转型，彻底避开运行时检查开销
- Java 中善用泛型限定（<T extends Dog>）或 sealed class + switch 表达式，让类型分支更清晰、更易维护
类型检查和向下转型不是 bug，是多态能力的副产品。关键在于清楚何时必须用，以及能否用更稳定的方式绕过它。
