std::unreachable仅在gcc 13+/clang 14+/msvc 19.35+且开启-o2或/o2时生效，旧版或低优化级下为空语句；用于switch需确保枚举全覆盖，否则运行时ub。
它只在编译器能静态证明路径不可达、且构建配置匹配时才真正删代码；写错或用错，程序会直接 UB，不报错也不警告。
std::unreachable 在哪些编译器和优化级别下才生效
它不是语言层面的运行时机制，而是编译器后端的“剪枝信号”。不满足版本和开关条件时，std::unreachable() 就是一条空语句，连警告都不会有。
-
GCC 13+/Clang 14+/MSVC 19.35+才提供标准std::unreachable；旧版（如 GCC 12）可能识别但不触发控制流优化 - 必须开启
-O2（GCC/Clang）或/O2（MSVC）；-O1下 Clang 常忽略，-O0下全当没写 - 启用 LTO（
-flto）可让不可达性跨函数传播，但链接变慢，且需所有目标文件统一启用 - 验证是否生效最直接的方式：
g++ --version确认版本，再用readelf -S your_binary | grep text对比加/不加前后的代码段大小
switch 中用 std::unreachable 替代 default 的典型陷阱
这是最常见也最容易翻车的用法。编译器不检查你“是不是真覆盖了全部枚举值”，它只信你写的控制流图。
- 对
enum class使用时，必须确保所有命名值都被case显式列出；若后续新增枚举项但漏改switch，运行时遇到新值就会 UB（不崩溃，直接跳进未定义状态） - 对裸
int或未限定范围的输入（如用户读入、网络解析结果）滥用default: std::unreachable();—— 编译器无法证明其不可达，优化不会发生，反而埋下崩溃隐患 - 某些
clang-tidy规则（如bugprone-branch-clone）会把std::unreachable()当作“分支已完备”信号，跳过枚举完整性检查，掩盖真实遗漏 - 更安全的做法：先用
static_assert验证枚举值数量（配合std::to_underlying+ 数组大小），再在default中放std::unreachable()
std::unreachable 与 __builtin_unreachable 的实际差异
别把它当成纯语法糖。两者在模板实例化、调试信息、跨平台行为上差异明显。
-
std::unreachable是 C++23 标准函数，声明在<utility></utility>，类型安全，不污染全局命名空间；__builtin_unreachable是 GCC/Clang 扩展，MSVC 不支持，需宏封装 - 在模板中，
std::unreachable()可参与 SFINAE（虽不推荐），而__builtin_unreachable()在非实例化模板里可能引发硬错误 - GDB 调试时，
__builtin_unreachable常被标记为 “no debug info”，GDB 直接跳过该行；std::unreachable更可能保留符号，便于追踪崩溃点（尽管仍不该到达） - 部分旧版 Clang 对
__builtin_unreachable的控制流分析更激进（比如提前删除 dead store），而std::unreachable在早期实现中可能被当作普通调用处理
它只在编译器能静态确认不可达、且你确保逻辑绝对正确的位置才该出现；一旦涉及外部输入、虚函数分发、运行时变量判断或未受控的枚举扩展，就不是提示优化，而是埋雷。看汇编确认是否删了对应分支，比任何经验都可靠。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
