应避免在继承体系中用 static_cast 做向下转型，因其不检查实际类型，易导致未定义行为；应优先使用 dynamic_cast 并校验，或通过多态、访问者模式等设计消除类型转换。
避免在继承体系中用 static_cast 做向下转型
当你写 static_cast<derived>(base_ptr)</derived> 时，编译器不会检查 base_ptr 实际指向的是否真是 Derived 对象。一旦不是，访问成员或调用虚函数就直接触发未定义行为——崩溃、静默数据错乱都可能。
常见错误现象：程序在 debug 模式下正常，release 下偶发 crash；或者对象布局因虚继承/多重继承变化后，原本“能跑”的代码突然出错。
- 只在你 100% 确认类型关系且无运行时不确定性时才用
static_cast向下转（例如单元测试里构造确定对象） - 所有来自外部输入、网络、容器、工厂函数返回的基类指针，一律视为“类型未知”，禁用
static_cast向下转 - 若必须向下转，改用
dynamic_cast并始终检查返回值：if (auto* d = dynamic_cast<derived>(ptr)) { ... }</derived>
用多态替代类型转换来消除判断分支
大量 dynamic_cast 或 static_cast 往往是设计信号：你在用类型判断代替行为抽象。比如写一堆 if (auto* a = dynamic_cast<a>(p)) { a->doA(); } else if (auto* b = dynamic_cast<b>(p)) { b->doB(); }</b></a>，这本质上是手动模拟虚函数表。
性能影响明显：dynamic_cast 在深继承树中是 O(n) 时间复杂度，每次调用都要遍历 RTTI 结构；而虚函数调用是 O(1) 的 vtable 查表。
立即学习“C++免费学习笔记（深入）”；
- 把分支逻辑提取成纯虚函数，让派生类各自实现，调用
ptr->handle()即可 - 若需不同返回类型或参数，用访问者模式（Visitor）或 std::variant + std::visit 替代运行时类型检查
- 避免在 hot path（如渲染循环、高频消息处理）中出现任何
dynamic_cast
用 enum class + 安全校验代替裸指针类型猜测
有些代码试图靠一个整型 tag 字段（如 int type_id）配合 static_cast 来“恢复”对象类型，这是高危操作。tag 值可能被篡改、序列化损坏、越界，而 static_cast 不做任何验证。
例如 enum class ObjectType { Player, Enemy, Item };，从文件读出 int raw = 99; 后直接 auto t = static_cast<objecttype>(raw);</objecttype> —— 编译通过，但 t 是非法值，后续 switch 或比较都不可靠。
- 永远不要对来自外部的整数做无条件
static_cast到enum class - 封装校验函数：
ObjectType safe_cast_to_object_type(int raw) { if (raw >= 0 && raw (raw); throw std::runtime_error("invalid object type"); } - 更进一步，用
std::optional<objecttype></objecttype>作返回类型，让非法输入显式失败而非静默接受
禁用 C 风格转换并启用编译器警告
(Derived*)ptr 这种写法会绕过所有类型安全机制，编译器无法区分你是想移除 const、做数值转换，还是强行 reinterpret。它同时激活了 const_cast、static_cast、reinterpret_cast 的能力，等于主动放弃编译期防护。
容易踩的坑：搜索代码时根本找不到这些转换（正则 \([^\)]+\)\* 太宽泛），Code Review 也极易漏掉；线上问题回溯时，看到这种写法基本等于“这里放弃了类型安全”。
- 在编译选项中加入
-Wold-style-cast（GCC/Clang）或/Wall（MSVC）并设为 error - CI 流水线里用 clang-tidy 检查
cppcoreguidelines-pro-type-cstyle-cast规则 - 已有代码迁移时，逐个替换为明确意图的命名 cast，哪怕暂时保留原有逻辑，也要先让转换意图可见
实际项目中最容易被忽略的是：类型转换不是孤立语句，而是整个对象生命周期和所有权模型的一部分。比如用 static_cast 转换智能指针所管理的对象类型时，若没同步更新 std::shared_ptr 的删除器或别名构造，可能引发 double-free 或悬垂引用——这类问题比单纯的类型不匹配更隐蔽，也更难调试。
