std::unreachable 在 GCC 12+、Clang 14+、MSVC 19.32+ 才真正起作用，旧版本仅作普通函数调用而不优化；它无副作用、不抛异常、不生成汇编指令，区别于 abort() 和 __builtin_unreachable()。
std::unreachable 在什么编译器版本才真正起作用？
它不是“写了就优化”，而是依赖编译器对 std::unreachable 的内建识别和后端死代码消除能力。GCC 12+、Clang 14+、MSVC 19.32+ 才把它当作真正的无返回（noreturn）语义处理；旧版本可能只当普通函数调用，甚至不报错但完全不优化。
常见错误现象：std::unreachable() 被调用后，后续代码仍出现在汇编里，或者 -O2 下没触发任何路径剪枝。
- 确认编译器版本：用
g++ --version或clang++ --version核对 - 开启足够高的优化等级：
-O2或-O3，-O1通常不够 - 避免在模板推导上下文中隐式实例化未被优化的重载（比如误写成
std::unreachable<void>()</void>）
std::unreachable 和 abort() / __builtin_unreachable() 有什么关键区别？
std::unreachable() 是标准、无副作用、纯语义断言；abort() 会实际调用运行时函数并终止进程；__builtin_unreachable() 是 GCC/Clang 特有内建，非标准且行为细节随编译器变化。
使用场景：你想让编译器“确信”某分支永不可达（如 switch 覆盖所有 enum class 值后加 default），又不想引入运行时开销或信号干扰测试流程 —— 这时 std::unreachable() 是唯一干净选择。
立即学习“C++免费学习笔记（深入）”；
-
std::unreachable()不抛异常、不调用任何函数、不产生栈帧，汇编中常被直接删掉 -
abort()即使在-O3下也会留下调用，还可能触发 sanitizer 检查 -
__builtin_unreachable()在 ICC 或 MSVC 下不识别，可移植性差
在 switch 中漏写 default 时，std::unreachable 能替代 exhaustive 检查吗？
不能。它不提供编译期枚举完备性检查，只是告诉编译器“到这里不可能发生”，但不会帮你发现漏了哪个 case。
典型误用：给一个 enum class Color { Red, Green, Blue }; 写了三个 case，然后加 default: std::unreachable(); —— 表面安全，实则掩盖了未来新增枚举值时的维护风险。
- 真正安全的做法是配合
[[fallthrough]]+ 编译器警告：-Wswitch-enum（GCC/Clang）或/we4061（MSVC） - 若坚持用
std::unreachable()，必须确保switch已显式覆盖所有枚举值（可用static_assert配合sizeof...(values)辅助验证） - 注意：C++23 允许
enum class的非穷尽switch默认行为是未定义行为，std::unreachable()只是让这个 UB 更容易被编译器利用，而非修复它
std::unreachable 放在 if constexpr 外部会怎样？
如果写在模板中、但不在 if constexpr 分支内部，它可能被实例化进所有特化路径，导致本该被丢弃的代码仍参与编译 —— 编译失败或生成冗余指令。
示例错误：
template<bool B>
void foo() {
if constexpr (B) {
// ...
}
std::unreachable(); // 错！B==false 时也实例化，直接编译失败
}
正确做法是把 std::unreachable() 严格限制在已被 if constexpr 确认为“永不进入”的分支末尾：
- 永远放在
if constexpr (false)分支里，或else后紧跟（且确保前面所有if constexpr已穷尽逻辑） - 不要放在函数体顶层、循环外、或任何可能被常规控制流到达的位置
- 尤其警惕宏展开后意外插入到非 constexpr 上下文
最易被忽略的一点：它不改变模板实例化规则 —— 只要语法上能到达，编译器就得尝试实例化。所谓“死路径”，必须从编译期控制流上彻底切断，而不是靠运行时语义暗示。
