std::unreachable() 仅在编译器能静态确认路径不可达时（如枚举全覆盖的default、if constexpr false分支）配合-o2/-o3优化才触发死代码消除，调试构建下无效且调用std::terminate。
std::unreachable 在什么场景下真正起作用
它只在编译器能**静态确认该路径永不执行**时，才可能触发优化。比如 switch 枚举值全覆盖后加的 default 分支、if constexpr 的 false 分支、或 assert(false) 被禁用后的兜底逻辑。运行时才决定走不到的地方（如 if (ptr == nullptr) 后跟 std::unreachable()）基本没用——编译器无法证明 ptr 一定非空。
- 必须配合 -O2/-O3 且启用内联和死代码消除（GCC/Clang 默认开，MSVC 需
/O2） - 仅当控制流分析能推导出“此处不可达”时，编译器才敢删后续指令或调整寄存器分配
- 对调试构建（
-g -O0）完全无效，std::unreachable()会变成实际调用（抛std::terminate）
为什么不用 abort() 或 __builtin_unreachable()？
abort() 是运行时终止，编译器看到它不会假设“此路不通”，只会当普通函数调用处理；而 __builtin_unreachable() 是 GCC/Clang 特有，可移植性差，且语义上不表示“程序逻辑错误”，只是提示“这里不该到”。std::unreachable() 是 C++23 标准方案，语义清晰：这是程序员主动声明的逻辑死区。
-
std::unreachable()不抛异常、不调用任何函数，纯编译器提示（在支持的优化级别下） - 相比
assert(false)，它不依赖NDEBUG宏，在发布版中依然有效 - 某些编译器（如 MSVC 19.35+）对
std::unreachable()的识别比__assume(0)更稳定
常见误用：这些写法几乎不触发优化
编译器静态分析能力有限，很多看似“显然不可达”的代码，实际无法被识别。以下模式基本白写：
- 在
if (x > 100)分支里写std::unreachable()—— x 是运行时变量，编译器不知道范围 - 放在虚函数重写末尾，期望删掉父类默认实现 —— 多态分发路径无法静态判定
- 在模板函数里对未实例化的分支使用 —— 实例化前无控制流图，优化器看不到
- 和
volatile变量读写混用 —— 编译器不敢重排或删除带副作用的操作
看汇编确认是否生效最靠谱
别猜，直接看生成的汇编。加 -O2 -S 输出 .s 文件，搜索对应函数名，观察含 std::unreachable() 的分支是否：消失、被替换为 ud2（x86）、或只剩跳转指令。关键点：
- GCC 12+ / Clang 15+ 对
std::unreachable()支持较完整；老版本可能降级为__builtin_unreachable()或忽略 - 若该路径原本就因其他原因（如常量传播）被删，你无法区分是
std::unreachable()起的作用还是别的优化 - 即使优化生效，也只影响该函数内联后的上下文；跨函数边界时，效果受限于内联决策
真正起效的前提很具体：编译器得信你，而它只信它自己能证伪的东西。写 std::unreachable() 不是为了“告诉编译器别跑这儿”，而是给它一个它能用上的逻辑锚点。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
