std::unreachable() 仅在gcc 13+/clang 14+/msvc 19.35+、-std=c++23、-o2或更高优化级且包含时触发死代码消除；否则为空语句，误用将导致未定义行为。
std::unreachable() 不是“加了就删代码”，它只在编译器能静态证明该路径永不执行、且构建配置完全匹配时，才真正触发死代码消除和分支剪枝。
std::unreachable 在哪些编译器版本和优化级别下才起作用
它不是语言特性，而是编译器后端的控制流剪枝信号。不满足以下全部条件时，std::unreachable() 就是一条空语句：
- GCC 13+ / Clang 14+ / MSVC 19.35+（旧版如 GCC 12 可能识别但不优化）
- 显式启用 C++23 标准：
-std=c++23 - 优化等级至少为
-O2（GCC/Clang）或/O2（MSVC）；-O1下 Clang 常忽略，-O0下多数编译器仅当它不存在 - 必须包含
<utility></utility>头文件，否则编译失败
验证是否生效最可靠的方式是：加 -O2 -S 生成汇编，搜索对应函数，看含 std::unreachable() 的分支是否被彻底删除、替换为 ud2（x86）或消失不见。
switch 中用 std::unreachable 替代 default 的典型误用
这是最常见也最危险的用法。编译器不检查你“有没有漏 case”，只按你写的控制流图做推导：
- 对
enum class E { A, B };，若后续新增C但未补case E::C:，运行时传入E::C会直接跳进std::unreachable()—— 行为未定义，不崩溃也不报错，结果不可预测 - 对裸
int或外部输入（如网络解析值）写switch(x) { case 0: case 1: default: std::unreachable(); }，编译器无法证明x只能是 0 或 1，优化不会发生，反而埋下 UB 隐患 - 某些
clang-tidy规则（如bugprone-branch-clone）看到std::unreachable()就跳过枚举完备性检查，掩盖真实遗漏
安全做法是：先用 static_assert 配合 std::to_underlying 或数组大小验证枚举值数量；再配合 -Wswitch-enum（GCC/Clang）或 /we4061（MSVC）强制警告未覆盖的枚举项。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
std::unreachable 与 abort()、__builtin_unreachable() 的关键差异
三者语义和行为完全不同，不能混用：
-
abort()是运行时终止，生成实际调用，即使-O3也删不掉，会触发 sanitizer、留下栈帧；std::unreachable()在支持条件下被完全删除，汇编里不留痕迹 -
__builtin_unreachable()是 GCC/Clang 扩展，MSVC 不认；std::unreachable()是标准函数，头文件<utility></utility>中声明，模板中可参与 SFINAE（虽不推荐），调试信息更可能保留（GDB 能定位到该行） -
__assume(0)（MSVC）语义是“假设条件为假”，而std::unreachable()是直接声明“此处不可达”，后者更严格，编译器更容易据此做寄存器重用、基本块合并等激进优化
它无副作用、不抛异常、不修改寄存器，但也不做任何运行时检查——一旦跑进去，就是未定义行为。
哪些写法几乎从不触发优化
编译器静态分析能力有限，很多看似“显然不可达”的路径，根本无法被识别：
- 在
if (x > 100)分支末尾写std::unreachable()：x 是运行时变量，编译器不知道其范围 - 放在虚函数重写末尾，期望删掉父类默认实现：多态分发路径无法静态判定
- 在模板函数中对未实例化的分支使用：实例化前无控制流图，优化器看不到
- 与
volatile变量读写混用：编译器不敢重排或删除带副作用的操作
真正起效的场景非常窄：枚举全覆盖的 default、if constexpr(false) 分支、或 assert(false) 被禁用后的 fallback。别把它当成逻辑兜底，它只是给编译器的一个强提示信号。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
