std::unreachable 是 c++23 标准化无返回函数，语义承诺调用点后控制流绝不会到达，使编译器可彻底删除不可达分支、优化常量传播与 cfg 结构，但误用将导致未定义行为。
std::unreachable 是什么，为什么它能优化分支
std::unreachable 是 C++23 引入的无返回值函数，语义上表示「此处控制流绝不会到达」。编译器看到它，会将后续代码视作死代码（dead code），并据此消除整条不可达分支——不只是跳过执行，而是从生成的指令中彻底删掉。
它不是 assert(false) 或 __builtin_unreachable() 的简单包装，而是标准化、可移植、有明确语义的契约：你保证调用点之后无合法执行路径。编译器信这个承诺，就能做更激进的常量传播和分支裁剪。
在 if/else 分支中用 std::unreachable 避免冗余代码生成
典型场景是枚举 switch 覆盖所有 case 后，default 分支本应不存在，但为防未来漏加 enum 值而保留。此时写 std::unreachable() 而非空 return 或 abort，能让编译器确认该分支永不执行。
例如：
立即学习“C++免费学习笔记（深入）”；
enum class Color { Red, Green, Blue };
void handle(Color c) {
switch (c) {
case Color::Red: /* ... */ break;
case Color::Green: /* ... */ break;
case Color::Blue: /* ... */ break;
default: std::unreachable(); // ← 编译器知道这里进不去
}
}
若改用 abort() 或 throw，编译器仍需生成调用桩和栈展开逻辑；而 std::unreachable() 允许直接删除整个 default 块的指令序列，连跳转判断都可能被省略。
- 必须确保调用点确实不可达，否则行为未定义（UB），运行时崩溃不负责诊断
- 不能用于模板实例化中可能被实例化的“假不可达”路径（比如 SFINAE 推导失败后误标 unreachable）
- Clang/GCC 在 -O2 及以上才充分启用基于它的优化；MSVC 需 /O2 + /std:c++23
和 __builtin_unreachable / __assume(0) 的关键区别
std::unreachable() 是标准设施，跨平台语义一致；而 __builtin_unreachable()（GCC/Clang）或 __assume(0)（MSVC）是编译器扩展，行为细节依赖具体实现，且可能被忽略或产生不同优化效果。
更重要的是：扩展内置函数通常不参与 SFINAE 或 consteval 判断，而 std::unreachable() 是普通函数，在 constexpr 上下文中也可使用（只要不实际执行）。
-
__builtin_unreachable()在某些旧版 GCC 中可能导致调试信息错乱 -
__assume(0)在 MSVC 中仅影响优化器，不改变 ABI 或异常处理模型 -
std::unreachable()被设计为可在consteval函数中出现（作为控制流终点），扩展函数做不到这点
容易被忽略的底层影响：它改变控制流图（CFG）结构
编译器前端构建 CFG 时，std::unreachable() 会标记当前基本块为“无后继”，这直接影响循环分析、寄存器分配和尾调用识别。例如，在递归末尾用 std::unreachable() 替代 return，可能让编译器放弃尾调用优化——因为它不再认为该路径有明确返回边。
另一个隐蔽点：链接时优化（LTO）中，如果某个内联函数里含 std::unreachable()，而调用方又恰好满足其前置条件，整个函数体可能被完全折叠，连符号都不留下。
真正难的是保证「逻辑不可达」与「编译器可证明不可达」一致——比如依赖未初始化变量的值做判断后跟 std::unreachable()，编译器大概率无法推导，反而引入 UB。
