std::unreachable仅在gcc 13+/clang 14+/msvc 19.35+、-std=c++23、-o2或更高优化级且用于enum class全覆盖switch时才真正触发死代码消除；否则为空语句或引入ub。
std::unreachable 不是“加了就删代码”，它只在编译器能静态证明某条路径永不执行、且构建配置完全匹配时，才真正触发分支剪枝和死代码消除；写错位置或开错优化等级，它就是一条空语句，甚至引入运行时 UB。
哪些编译器版本和优化级别下 std::unreachable 才真正生效
它不是语言特性，而是编译器后端的控制流剪枝信号，必须同时满足三项硬性条件：
- GCC 13+ / Clang 14+ / MSVC 19.35+ —— GCC 12 或 Clang 13 可能识别函数签名，但不会删除对应分支
- 显式启用 C++23 标准：
-std=c++23（缺此参数，#include <utility></utility>会编译失败） - 优化等级至少为
-O2（GCC/Clang）或/O2（MSVC）；-O1下 Clang 常忽略，-O0下多数编译器调用std::terminate而非优化
验证是否生效最可靠方式：用 g++ -O2 -S main.cpp 生成汇编，搜索对应函数名，看含 std::unreachable() 的分支是否被彻底移除、替换为 ud2（x86）或只剩跳转指令。
在 switch 中对 enum class 使用 std::unreachable 的安全写法
这是唯一推荐的典型场景，但必须严守边界：
- 仅限
enum class（强类型枚举），普通enum或int不行 —— 编译器靠枚举定义的封闭性做静态推导 - 所有命名值必须显式列出
case，例如enum class E { A, B, C };就得写满三个case - 新增枚举成员后，必须同步更新
switch，否则运行时传入新值会直接 UB（不崩溃、无警告、结果不可预测） - 配合
static_assert验证枚举值数量，例如：static_assert(std::to_underlying(E::C) == 2);；再启用-Wswitch-enum（GCC/Clang）或/we4061（MSVC）强制检查遗漏
⚠️ 注意：static_cast<e>(42)</e> 这类绕过类型检查的转换，会让值落在命名范围外，std::unreachable 无法防御。
if 分支里哪些地方加 std::unreachable 几乎没用
绝大多数运行时判断分支加了也白加，因为编译器无法静态证明不可达：
-
if (x > 100) { std::unreachable(); }——x是变量，编译器不知道取值范围 -
if (ptr == nullptr) { /* handle */ } else { std::unreachable(); }—— 空指针检查是运行时逻辑，编译器无法假设ptr必非空 -
virtual函数末尾、模板未实例化分支、与volatile混用 —— 都无法触发剪枝
唯一例外是编译期常量分支：if constexpr (false) { std::unreachable(); }，此时模板实例化阶段就能剪掉整块代码。
为什么不能用 std::unreachable 替代 assert(false) 或 abort()
三者语义完全不同，混用会破坏预期行为：
-
assert(false)依赖NDEBUG宏，发布版中完全消失，不提供任何优化提示 -
abort()是运行时终止，生成实际调用，即使-O3也删不掉，会触发 sanitizer、留下栈帧 -
std::unreachable()在支持条件下被彻底删除，汇编里不留痕迹；但它不兜底——漏写case不报错，只等运行时 UB - 调试时，
__builtin_unreachable()常被 GDB 标记为 “no debug info” 而跳过，std::unreachable()更可能保留符号位置，便于定位“本不该到达却到达”的崩溃点
真正容易被忽略的是：它不提供编译期完备性保证。你写了 std::unreachable()，不代表编译器帮你检查了逻辑完整性；它只信你写的控制流图，不信你的业务约束。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
