那些年。
你写的是 C。
写着写着。
就写成了“带点 class 的 C”。
编译器不怎么唠叨。
IDE 也不怎么提醒你：这行代码危险。
你要把一个东西当成另一个东西用。
最顺手的，还是那一对括号。
你写的时候很放心。
直到它真的把你叫醒。
没有它之前，我们怎么凑合
旧办法就一种：(T)expr。它短，眼前也确实好用，写起来还挺像“我知道我在干什么”。当年项目赶进度，这就是最顺手的选择。
但它不表达意图：读你代码的人不知道你是在做数值转换、赌一次向下转型，还是只是想撕掉 const。编译器也不知道，于是它既帮不了你，也拦不住你。更阴的是，这类错往往不会立刻炸，会挑一个线上最忙的晚上用堆栈逼你回忆“当年这行括号到底想干嘛”。
一次很典型的线上崩溃
当年我刚接手一个老项目，崩溃日志很干净：SIGSEGV。地址还挺整齐，0x00000010。
一看就像在解引用一个“差一点就不是空指针”的东西。翻到代码，你会看到那种熟悉的写法。
Base* p = get_from_somewhere();
auto* d = (Derived*)p;
d->foo();
作者当时的想法也很直：“我知道这里拿到的就是 Derived。”
于是他就用了一把“最省事”的强转。项目跑了两年，直到某次改动让 get_from_somewhere() 偶尔真的会返回别的派生类，这个强转就从“省事”变成了“偶发炸弹”。
这篇文章只解决一个“当年真实会痛”的问题
我这篇只干一件事：你在项目里看到一行强转的时候，怎么在十秒钟内判断它到底在声明什么意图。
然后你就知道该换成哪一种 xxx_cast，以及“失败路径”应该怎么写出来。
C++ 为什么要发明四种 cast
C 时代只有一种 cast，也就是你熟悉的 (T)expr。它短、顺手，也确实能解决问题；麻烦在于它太“万能”，看起来像一回事，实际可能干了完全不同的四件事。到了 C++，你写一次强转，其实是在做四选一：
static_cast<T>(expr);
dynamic_cast<T>(expr);
const_cast<T>(expr);
reinterpret_cast<T>(expr);
它们都长得像“把 expr 变成 T”，但语气完全不同：有的是正常的语义转换，有的是多态体系里的验货转型，有的只是撕 const，也有的在改你对这段比特位的解释方式。
一个 C 风格 cast 在 C++ 里可能对应 static_cast，也可能对应 const_cast，甚至可能偷偷走到了 reinterpret_cast，所以读代码的人很难在第一眼判断你到底想干什么。
一旦你搞错了，它往往不会立刻报错。 它会在某个你最不想加班的晚上，用最离谱的方式把你叫醒。
所以 C++ 把 cast 拆成四种，不是为了让你多记几个关键字，而是让你在写转换时顺手把意图写在代码里。你把 cast 写对了，读你代码的人就少猜一层，也就少踩一层坑。
先记住一个“对象模型视角”的问题
你每次写 cast，本质都在回答一个问题：你希望编译器怎么理解这块内存。有时你只是换个单位（比如 int 到 double），有时是在继承体系里换一个视角（比如把 Derived* 当成 Base*）。
但也有时候，你是在说“别管类型系统了，我就按这套比特位来解释”。四种 cast，就是把这些不同的意图拆开分别命名。
static_cast：最常用的“正常转换”
static_cast 的气质很像“编译期推导”：它不做运行时检查，只在类型系统允许的范围内帮你完成转换。它最常见的用途是数值/枚举这类语义转换，以及继承体系里的向上转型。
double d = static_cast<double>(42);
int x = static_cast<int>(3.14);
这类数值转换很正常，但后果要你自己承担：截断、溢出、精度损失都不会有人替你兜底。
static_cast 的价值是让这种“我确实要转”的意图显式化，而不是靠读者去猜。
Derived* pd = new Derived();
Base* pb = static_cast<Base*>(pd);
向上转型也很正常，因为派生类对象里确实“包含”一个基类子对象；必要的指针调整编译器知道怎么做。很多时候你把这步写出来，只是在提醒读者：这里发生过一次视角切换。
但真正容易出事的，是你拿它去做向下转型。
Base* pb = get();
Derived* pd = static_cast<Derived*>(pb);
这行代码不会检查 pb 指向的对象到底是不是 Derived；如果它不是，你拿到的是一个“看起来很像 Derived*”的指针，但它指向的内存并不满足 Derived 的对象布局。
编译器也不会提醒你，接下来任何成员访问都是未定义行为，你再也不能用推理去解释它会怎么坏。在多态体系里，如果你需要向下转型，又不能 100% 证明真实类型，我更建议你先想到 dynamic_cast。
dynamic_cast：多态体系里的“带验货的转型”
dynamic_cast 是给“运行时真实类型”准备的：你想向下转型，但你希望先验货。它的前提是基类必须是多态类型，也就是至少有一个虚函数（实际项目里通常是一个虚析构）。
struct Base {
virtual ~Base() = default;
};
struct Derived : Base {
void foo() {}
};
Base* pb = get();
if (auto* pd = dynamic_cast<Derived*>(pb)) {
pd->foo();
}
然后你就可以安全地做向下转型：如果失败，指针版本会返回 nullptr，这就是它的“验货结果”。代价是你得把失败路径写出来，但这通常正是你想要的“显式”。
Base& rb = get_ref();
Derived& rd = dynamic_cast<Derived&>(rb); // 失败会抛 std::bad_cast
引用版本更严格：失败会抛异常，所以你一般只在“失败就是异常”的语义下使用它。
从对象模型角度看，dynamic_cast 做了两件事：运行时确认真实类型，以及在多重继承等复杂布局下把指针调整到正确的子对象位置。它慢一点，但也更安全一点；你要付出的代价是接受 RTTI 的存在，并且老老实实把失败路径写出来。
const_cast：只改 const，别偷偷改别的
const_cast 很单纯：它只做一件事，添加或移除 const/volatile。它不负责让对象“变得可写”，它只是在类型系统层面把你的意图写出来。
void f(int* p);
const int x = 42;
f(const_cast<int*>(&x));
这段代码能编译，但你如果在 f 里写 *p = 0;，那就是未定义行为。
因为 x 本来就是一个真正的 const 对象，你只是把类型系统的警告撕掉了，对象本身并不会因此变得“可写”。
const_cast 的典型用途更多是应付接口历史包袱：比如某些老 API 不肯收 const char*。你用它其实是在告诉读代码的人：“我知道我在干什么，我只是为了匹配接口签名，我不会去改这段数据。”
如果你发现自己经常需要 const_cast，更好的方向通常是把接口改成 const 正确的样子。
reinterpret_cast：我不建议你习惯性使用它
reinterpret_cast 的意思几乎是：“别管类型系统了。” 它允许你把一段比特位按另一种类型来解释，通常只在非常底层的活里出现。
你写它的时候，最好已经在脑子里把对齐、生命周期、严格别名规则过了一遍。
std::uintptr_t u = get_address();
auto* p = reinterpret_cast<std::byte*>(u);
这类“指针和整数互转”在做底层、序列化、JIT、内存映射的时候会出现。
它也常见于一些“看起来很聪明”的技巧，比如把一个对象指针硬转成另一个对象指针。
void* raw = get_raw();
auto* p = reinterpret_cast<MyType*>(raw);
这里最危险的点不是语法，而是前置条件一大堆：你得同时保证这块内存里真的放着一个 MyType 对象、对齐满足 alignof(MyType)、对象生命周期已经开始，并且接下来的访问不违反严格别名规则。
任何一个条件不满足，你得到的都不是“偶尔错”，而是“你永远解释不清的错”。
如果你想做的是“按比特位拷贝”，现代 C++ 更推荐用 std::memcpy，或者 C++20 的 std::bit_cast。它们至少把意图写得更清楚，也更容易被审查和维护。
一个实用的选择方式
当你手已经伸向 cast 的时候，先停半秒，问自己一句：你到底想改变什么。
如果你回答不出来，这行 cast 大概率该删掉，或者换成一个带名字的函数把前置条件讲清楚。你也可以把它当成一段“写给自己看的选择器”，用来强迫自己把意图说清楚。
// 你到底想改变什么？
// 1) 改语义：数值/枚举/向上转型 -> static_cast
// 2) 多态向下转型，并且需要验货 -> dynamic_cast
// 3) 只改 const/volatile -> const_cast
// 4) 按比特位解释（底层活） -> reinterpret_cast
它不是法律，它只是提醒你：在写 cast 之前，先把“意图”说清楚。
你把意图说清楚，后面这四个 xxx_cast 通常就不会选错太多。
想改语义（比如数值、枚举、向上转型），优先 static_cast；这类转换的风险更多是精度或截断，但至少还在类型系统的轨道上。多态体系里要向下转型，又不能 100% 证明真实类型，优先 dynamic_cast；你需要写出失败路径，换来的是“验货”由运行时替你做。
只想解开/补上 const，用 const_cast，并且先想清楚对象是否真的可写：它只是撕掉类型系统的警告，不会让一个本来只读的对象变可写。真要做底层比特位解释，那才轮到 reinterpret_cast；对齐、生命周期、严格别名规则这三件事，只要有一件没想清楚，就别碰它。
最后再把那句老话说一遍
能不用 cast，就不用；但如果你在业务代码里频繁写 cast，很多时候不是你“爱强转”，而是接口设计在逼你补债。
把转换收口到一个带名字的函数里，让名字替你把前置条件讲清楚；接手老代码时，看到一行 (T)expr，要么换成具体的 xxx_cast，要么把 C 风格 cast 的编译器警告打开。
别让读者猜。
把意图写在代码里。